That's quite likely a false positive. The way object finalization is implemented in most JVMs (since Java 2, at least) is to use a queue of Finalizer references - the queue is implemented as a linked list, hence you see the chain. The JVM has a dedicated thread named "finalizer thread" that processes this chain; it'll get to process them sooner or later. The fact these references are enqueued (that is, participate in the chain) means that the objects they reference are not reachable through any other reference anymore, thus will be garbage collected - eventually. There's no time guarantee when does finalization run.
You should probably look elsewhere if you're getting an OutOfMemoryError or unusually high memory usage. Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com On 2009.12.07., at 17:51, Keith wrote: > I am using Rhino to compile and run .js files from within a servlet. > When I hit the servlet from a browser several times, I see each > execution creates one or may be more instances of > java.lang.ref.Finalizer and never releases it. > > When I took a heap dump and analyzed it with Eclipse Memory Analyzer I > see each java.lang.ref.Finalizer refers to another instance of > Finalizer like a chain: > > java.lang.ref.Finalizer -> java.lang.ref.Finalizer - > > java.lang.ref.Finalizer -> java.lang.ref.Finalizer -> and so on. > > Also, each java.lang.ref.Finalizer would also refer to a > FileInputStream with the file descriptor value of -1. > > Inside the Servlet I am not compiling the .js files, I run it with > setOptimizationLevel(-1) which only interprets the files. Also, all > open files are clearly close inside of the finally clause. > > I wonder if there is a common flaw of some sort that would cause this > java.lang.ref.Finalizer chain in the heap. _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
