commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: logging: WeakHashtable
Date Fri, 12 Nov 2004 06:55:18 GMT
--- robert burrell donkin  wrote:

> On 11 Nov 2004, at 07:40, Brian Stansberry wrote:> 
> >  A couple things occurred to me as I looked.
> >  
> > 1)  The instances of Referenced are not cleared
> from the underlying 
> > table if their underlying references are cleared.
> > 2)  Passing null keys/values to put() does not
> result in a NPE.
> > 
> > One thought on #1 is to make Referenced a subclass
> of WeakReference 
> > instead of a wrapper.  You can then keep a
> ReferenceQueue and poll it 
> > to remove cleared references from the hashtable
> whenever get() is 
> > called.  This is similar to what WeakHashMap does.
> i had a bit of a think about the best way to do
> this. i think the 
> approach outlined would be best if this were a
> general implementation. 
> in this case, though, the majority of calls are
> going to be to get with 
> somewhat less going to put and very few to any
> others. i can't think of 
> any occasions when the symantics of put and get are
> influenced by the 
> presence of extra entries. so i've opted for code
> that simply purges 
> entries that have lost their referants which is
> called at the start of 
> other interrogative methods. the data returned will
> be more stale than 
> using a reference queue but i think that liveliness
> for put and get should be improved.
Yep, slowing down the critical get() just to sweep up
some dust in the corners makes no sense.

> i'd be grateful if people would take a look at the
> code and try to find 
> any holes in this approach or reasons why using a
> ReferenceQueue might 
> improve liveliness (preferably with patches)...

I was thinking about this and concluded that the
approach of iterating the Hashtable.entrySet() would
be faster since you're checking if either the key or
the value has been cleared.  Using a ReferenceQueue
for values would force you to use a reverse lookup
map, which seems inefficient.

But then I thought, wait, should the values be held in
WeakReferences?  In a typical case where the
application just calls LogFactory.getLog(), won't the
only reference to the LogFactory instance be the value
in the map?  In this case a lot of calls to getLog()
will end up going through the getFactory() discovery
mechanism as the GC keeps clearing the values from the


Do you Yahoo!? 
Check out the new Yahoo! Front Page. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message