Thanks for looking into it, Andreas! On 22.08.2008 00:15:00 Andreas Delmelle wrote: <snip/> > So, I was wondering about the role of the reference queue. Calling > poll() returns the first reference /if/ one is available, so it seems > likely that cleanSegment() does get called frequently enough, but > there's always the possibility that it returns without a reference > being available, yet. Or, as it happens, after throwing away only > roughly half of the references. > Maybe it's only those that are also effectively enqueued at the time > the cleanup is triggered (didn't try adding this to the stats yet).
Javadoc says about WeakReference that the queueing may happen at some point after the reference is cleared. But a delay alone doesn't explain that so many instances weren't cleared. I got the impression that the cleaning wasn't done for some cache segments at all because the threshold never got reached. Just a feeling. > In the meantime, I've made some changes, bypassing the > ReferenceQueue, and simply cleaning all buckets that map to the > segment in question, and now the behavior already seems more like > what I had in mind. > The first runs, each segment corresponds to one bucket, and the > output now shows the number dropping to 0% for the related bucket. Segments: always 32 Buckets: initially 8, rehash doubles the number of buckets each time That doesn't match what you're saying. Initially, 4 segments would share entries in 1 bucket. After a few rehashes, each segment would have its entries in a set of buckets. I think that's why in your patch the segment.count goes down into the negative (i.e. it's wrong). Plus, the removal of the reference queue polling just queues up references which are never cleared. I've fixed that locally. I'm going to try to fix the first problem above but I think that might not be possible without a performance penalty. Let's hope it's negligable. > See the attached patch. Still needs some cleanup, and haven't done > any long-running tests, nor checked the cache for other types. I > copied some, but not all of the added debug-code. > > There are still a few things that bug me about StringProperty's > cache, since for example, it is used in a lot of cases where not the > property but its String value is attached to the FOs (reducing the > benefits of caching somewhat, and probably explaining the large > number of stale entries here...) Stale entries, yes, but at least the String instances are reused because they come from the canonicalized StringProperty. And we're using WeakReferences which get claimed very early. I don't think there's much we can/need to do about that. > > Hope this helps some. Yes, it has shown me an aspect that I have missed. Jeremias Maerki
