4 Replies Latest reply: Jan 21, 2010 12:54 PM by jschellSomeoneStoleMyAlias RSS

    How to explain idling Finalizer Thread though huge Finalizer queue?

    843829
      First of all thanks for your attention!

      In our application we received an java.lang.OutOfMemoryError: "GC overhead limit exceeded" Exception resulting in a HProf heapdump image.
      The heap dump analysis shows that nearly 75% of the heap memory is only allocated and retained by the Finalizer ReferenceQueue instance.

      I assumed a blocking or long running finalize()-Method as the root problem, but this doesn't match my understanding of the stacktrace we received at the time of the exception:
      "Finalizer" daemon prio=10 tid=0x08103c00 nid=0x49d6 in Object.wait() [0x5385a000..0x5385a1d0]
         java.lang.Thread.State: WAITING (on object monitor)
           at java.lang.Object.wait(Native Method)
           - waiting on <0x61a94580> (a java.lang.ref.ReferenceQueue$Lock)
           at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
           - locked <0x61a94580> (a java.lang.ref.ReferenceQueue$Lock)
           at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
           at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
      From my point of view the Finalizer thread is idle and waiting for new incoming objects that need to be finalized.
      So the Finalizer Reference Queue should be empty, but isn't? Otherwise I'd expect a stacktrace where the Finalizer thread actually executes a finalize()-Method.

      Am I wrong? What is the explanation for this situation?
      What would be the best way to further track the problem: Triggering thread dumps on a regular basis to catch a potential long-running/blocking finalize() method in the stracktrace?

      I appreciate any support and further background hints!

      Best regards
      - Ben