I've tested only on Windows with Sun JDK 6.0_03 (dual core, non-multithreaded in MemoryEater). The reporter will have had a different setup but I don't know what it is without asking back. I believe it's JVM-independent. cleanSegment() does get called but I suspect it doesn't get called regularly for all segments to have the wanted effect of a clean-up.
I'm attaching my changes I've done while debugging. It might help you if you want to write out those statistics I've shown. Please note that I made CacheEntry static which makes the instance smaller. Good luck and thanks for helping! On 21.08.2008 18:38:51 Andreas Delmelle wrote: > On Aug 21, 2008, at 18:20, Jeremias Maerki wrote: > > Hi Jeremias > > > I've been made aware of a slow memory leak. I was able to identify > > PropertyCache as the leaker. It appears as if the cache segments don't > > get cleaned correctly. The majority of CacheEntry instances have a > > cleared reference but don't get removed from the buckets. In time that > > accumulates to millions of stale CacheEntries and a performance > > degradation. > > Ouch! > Did you happen to run the test on multiple platforms/JVMs? Are the > results the same? > I'll see if I can debug it on OS X tonight, to have a closer look at > what happens during cleanSegment() (and whether it gets called at all) > > > I'll post back once I have done this. > > > Later, > > Andreas Jeremias Maerki
PropertyCache debug patch.txt
Description: Binary data
