Second Code Review for WeakReference leak in the Logging API (6942989)

Jeremy Manson jeremymanson at
Wed Jun 23 11:38:44 PDT 2010

Hi Daniel,

I'm sorry I missed this (I heavily filter these lists, and check rarely).

My main feeling is that you are missing a good bet by not
reconstructing the Hashtable in LogManager and the ArrayList in Logger
every so often when you remove the loggers.  In a test case where
there are a LOT of short-lived loggers, the backing array for the
Hashtable can get very big.  It is permanent, and doesn't go anywhere.
 You can end up with a lot of extra memory lying around that way.

Specifically, when I didn't reconstruct those data structures, the
test case listed in the bug (where it just creates lots and lots of
anonymous loggers) killed the Java instance with an OOM, even if I
*did* clean up the weakreferences to the loggers.

I'm assuming you have a customer waiting for this - if that is similar
to their usage pattern, this fix may not fix their problem.

You obviously don't want to rebuild those structures every time,
though.  What I did in my change was to reconstruct the backing data
structures every time ~as many loggers were collected as were present
in the data structure.


On Fri, Jun 18, 2010 at 12:25 PM, Daniel D. Daugherty
<daniel.daugherty at> wrote:
> Greetings,
> I have a new version of my fix for the WeakReference leak in the
> Logging API done. This version uses ReferenceQueues; thanks to Eamonn
> McManus, Jeremy Manson and Tony Printezis for their insights on using
> ReferenceQueues. Here's a pointer to Tony's paper for background info:
> This version also has limits on the number of dead Loggers that are
> cleaned up per call; thanks to Alan Bateman for politely pushing me in
> that direction.
> The webrev is again relative to OpenJDK7, but the bug is escalated so
> the fix will be backported to the JDK6-Update train. So again, I'll
> need a minimum of two code reviewers.
> Here is the URL for the webrev:
> Thanks, in advance, for any reviews.
> Dan

More information about the hotspot-runtime-dev mailing list