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

[David Holmes]

Daniel D. Daugherty said the following on 06/11/10 11:50:
> On 6/10/2010 7:08 PM, David Holmes wrote:
>> I wonder about the performance implications of doing this search each 
>> time a logger is added? These types of cleanups are always a fine line 
>> between minimizing cleanup up on the main path, and ensuring too much 
>> garbage doesn't accumulate. I'm a little concerned this is a lot of 
>> clean up code (potentially) on the main path.
> 
> Agreed. In this particular case, I'm slamming down hard on the
> correctness side. The theory is that there shouldn't be too many
> Logger objects in the normal system and once you've added them,
> then this fix doesn't come into play.

So the original problem was exposed through excessive use of anonymous 
loggers ... but now if those loggers are no longer referenced the next 
anonymus logger created will trigger clean up of all such unreferenced 
loggers (well assuming the weak-ref has been cleared), so the set of 
children to traverse should be kept small.

But I still wonder if there are apps out there that will create large 
logger hierarchies ...

> Can I put you down as a "thumbs up"?

Yes. :)

David

> Dan
>