On Nov 14, 2007, at 21:38, Jeremias Maerki wrote:
The attached patch should fix the memory leak Chris described (in
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
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
if sending this task to a different thread really helps here at
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
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/
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. ;-)