commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [collections] any objections?
Date Wed, 09 Nov 2005 00:38:06 GMT
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 = loop.next;
>         }
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. None of this 
requires us to check using equals().

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message