commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Yu <>
Subject RE: [Collections][SUBMIT] ReferenceMap. Take FOUR.
Date Tue, 30 Jul 2002 02:01:09 GMT

(see below)

At 01:02 am 30-07-2002, you wrote:
> > Hi Paul,
> >
> > Shouldn't purge() only be called when mutators (write
> > methods) are called, not accessors (read methods)?
> >
> > My understanding is java.util.WeakHashMap only process the
> > ref queue (in the processQueue() method) when mutators are called.
>Actually, that was my initial understanding as well.  The
>"take three" version of ReferenceMap only purged during mutations.
>But after reviewing the source for java.util.WeakHashMap,
>I discovered that it in fact clears out its ReferenceQueue
>on all operations, even accessors (even simple ones like
>isEmpty()).  I'm looking at the 1.4 source, I'm not sure if
>previous versions of WeakHashMap behaved the same way.

I was looking at JDK 1.3 source. WeakHashMap clears the ref queue only in 
mutators in 1.3.
Perhaps it's worthwhile to do a diff to see why/what/how Sun changes 

> > If queueQueue() were called in accessors, iterators which are
> > backed by the map would get into an invalid state when
> > accessors were called. This breaks the Map interface contract.
> >
> > Or do I miss something?
>Although all of the Map implementations supplied by the JDK
>provide fail-fast iterators, the fail-fast behavior isn't
>specified by the Map contract.
>Also, although common Map implementations behave this way,
>it isn't required that a read operation not alter the state
>of the map.  For instance, in java.util.LinkedHashMap, the
>mere act of accessing a key can structurally modify the Map.
>(Apache's LRUMap behaves similarly).
>Basically the issue is that there's no such thing as an
>unmodifiable ReferenceMap.  Like WeakHashMap, it behaves as
>if an invisible thread is silently removing mappings.
>Note that ReferenceMap iterations in a single-thread context
>are safe, because the iterators don't purge stale entries
>(the iterators just skip over stale entries), and because
>no other thread is accessing the map.  In a multithreaded
>context, the iterations should be synchronized properly,
>which would lock out other operations, even read operations.

Probably you are right. The 1.3 impl misleads me. I've re-examined 1.3's 
WeakHashMap source. It seems the processQueue() method can have been safely 
called in *all* methods.

John Yu                       Scioworks Technologies
e:         w: +(65) 873 5989
w:   m: +(65) 9782 9610 

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

View raw message