On Dec 5, 2007, at 15:23, Chris Bowditch wrote:

Andreas L Delmelle wrote:
On Nov 27, 2007, at 20:06, Andreas L Delmelle wrote:

Hi Andreas,


I tested on Apple JVM 1.4.2 and 1.5.0 on OS X 10.4. Both single- and multi-threaded.
Heap remains stable here over hundreds of runs.
With multiple concurrent runs, my CPU usage easily reaches 180-190% (2 CPUs)

Just to confirm:
In the meantime, I have also run some tests with the same document on Windows XP SP 2 with different versions of the Sun JVM, running 2 concurrent threads on a Centrino Dual Core.
Classes compiled with 1.4 compatibility.
I managed to reproduce the NPE on Java 1.4.2 and 1.5.0, at random intervals, always between 50 and 250 runs.

Thanks for your perservance. Glad its not me going mad :)

Yeah, I thought you'd appreciate it for this very reason... :-)

Still weird though. Logically, from a Java POV, there is no reason why the NPE could ever occur, or IOW: if the NPE occurs, there would be a problem in the JVM's implementation of WeakReferences or synchronized code-blocks or in the garbage-collection algorithm or the thread-synchronization.

If the NPE occurs at that point, either of the variables 'entry' or 'e' would be null. 'entry' = the WeakReference that is obtained by polling the ReferenceQueue. The code-block in question will not be entered if this is null. Possibility A: If it /becomes/ null, this would mean that the WeakReference /itself/ (not its referent) is removed by the garbage- collector while there obviously exists a strong, local reference to it.

'e' = the WeakReference that is obtained by traversing the hash- bucket, looking for 'entry'. Possibility B: If this is null, this would mean that 'entry' could not be found. So, some other thread already cleaned up the stale entry, which would mean that ReferenceQueue.poll() has returned the same WeakReference for another call in that thread... but the only calls to poll() happen inside code-blocks that are synchronized on the CacheSegment to which the ReferenceQueue belongs. As such, they can never occur at the exact same instant. One always has to wait for the other. Come to think of it, one thing I haven't tried, is declaring the ReferenceQueue as 'volatile', but I somehow doubt this would help much here.

You mentioned that your tests were single-threaded. The cause of the NPE can therefore not be MT-related, which rules out Possibility B, and seems to point towards a quirk in the GC and its treatment of WeakReferences. :/

Anyway, enough ranting done. Just glad it worked out.



Reply via email to