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.

Jeremias Maerki

Attachment: jm-PropertyCache-MemLeak.diff.txt
Description: Binary data

Reply via email to