commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [collections] any objections?
Date Wed, 09 Nov 2005 18:20:55 GMT
On Wed, 2005-11-09 at 00:38 +0000, Stephen Colebourne wrote:
> robert burrell donkin wrote:
> > On Sat, 2005-11-05 at 10:39 -0700, Phil Steitz wrote:
> > the reported issues seem only to occur when synchronizedMap is used. has
> > anyone looked for a pattern in JVM versions?
> No, not yet
> > or tried to replicate using a multi-threaded test rig? 
> Bugzilla contains a basic multi-thread test
> > starting with the symptoms: if there is problem, it's not common and
> > occurs only when the map is full. AIUI the map is of a fixed maximum
> > size and when full the oldest entry is discarded and the space reused.
> Yes
> > the NPE occurs in LRUMap.reuseMapping which accords with the symptoms
> > (this code is only executed when full). so, there is no reason not to
> > focus on this method first.
> The bug report also has an error in addMapping
> > i may have missed something but i don't think that this isn't a strict
> > LRU implementation: rather, it removes the last recently used entry with
> > the same hashcode. here's the code:
> > 
> >         int removeIndex = hashIndex(entry.hashCode, data.length);
> >         HashEntry loop = data[removeIndex];
> >         HashEntry previous = null;
> >         while (loop != entry) {
> >             previous = loop;
> >             loop =;
> >         }
> The removeIndex is the index of the hash bucket, not the hash code. This 
> bit of code is simply trying to find the entry before that we want to 
> remove, where we already know the entry we want to remove. 

got that bit but missed the use of header to store order links to
entries. header is the start of a circular buffer used to store the
entries in order, right?

> None of this 
> requires us to check using equals().

true that wasn't the path i was travelling down. i was wondering whether
the bucket could ever be null (thus producing a NPE) but it can't be if
there is an entry is still in the map. doesn't seem to be any easy way
that it could happen given appropriate synchronisation. the other
candidate is for loop to become null but this shouldn't happen, should

is it time to take seriously the possibility of a bug in synchronisation
being an explanation?

- robert

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

View raw message