On Nov 14, 2007, at 21:38, Jeremias Maerki wrote:

The attached patch should fix the memory leak Chris described (in one of
my runs the number of CacheEntry instances after a full GC went down
from 10575 (169KB, before the change) to 386 (6KB, after the change).
I've run various documents through the multi-threading testbed
application (in the test directory) with up to 17 threads on my
dual-core CPU. The output seems to be fine. No corruption or failures.

When I was at 17 threads the VM monitor showed up to 700 concurrent
threads in the process (700 - 20 = 680 cleaner threads from
PropertyCache). Ouch. The log output basically didn't change during
those spikes.

Another observation: In util.concurrent's ConcurrentHashMap there's a
mechanism that triggers the restructuring only if 1/4 of the segments
vote for it. And it does all that without spawning new threads. I wonder if sending this task to a different thread really helps here at all, or
if it just makes everything more complicated.

Maybe... In any case, java.util.ConcurrentHashMap does not have to clean anything, since it is a 'hard' map. It only needs to bother with rehashing. The rationale was that, in this way, the put() method can return immediately, and the Thread that issued the put() --FOP's main thread-- can continue.

I've already got some ideas for using only one cleaner per instance.

Thanks for the helpful feedback and the patch. If you have any specific questions, just yell, and I'll do my best to remember/ explain...

I got the idea from an article I read. If I succeed in finding the link to it, I'll post it (it was somewhere on IBM's website, IIRC). One thing I do remember was that the author stressed "Do not try this at home!"... which of course made /me/ try it anyway. ;-)



Reply via email to