On Sat, 2005-11-05 at 10:39 -0700, Phil Steitz wrote:
> Big +1. Agree with Stephen and share frustration over 32573. I have
> spent quite a few hours trying to replicate or "prove" that the only
> way to make this happen is via unsynchronized access.
proving that would be tough :-/
the reported issues seem only to occur when synchronizedMap is used. has
anyone looked for a pattern in JVM versions?
or tried to replicate using a multi-threaded test rig?
> Another set of eyes on that issue would be great.
i can't claim any deep understanding of the code but sometimes
discussions can throw up a solution. please jump in and correct my
misunderstandings...
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.
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.
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;
}
this is the code suspected to throw the NPE.
if this is not a strict LRU then i suspect that loop could legitimately
be null after some entries are reused when the hashCode's are not evenly
distributed. this would be consistent with the symptoms reported and may
be possible to unit test (with difficulty).
does this seem possible?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
