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
jm-PropertyCache-MemLeak.diff.txt
Description: Binary data
