[concurrency-interest] ConcurrentHashMap footprint and contention improvements

Martin Buchholz martinrb at google.com
Fri Apr 15 14:16:08 EDT 2011

Taking another look, it appears that if we have an existing key k,
then put(k,v) (or corresponding entry.setValue(v)) will affect neither
the segment modcount (only insertions and deletions do that) or the
hash (which is a function of k), which would mean that none of the
retry loops would notice that the map is in flux.


On Fri, Apr 15, 2011 at 07:54, Doug Lea <dl at cs.oswego.edu> wrote:
> On 04/15/11 10:33, Martin Buchholz wrote:
>> The older code that used segment modcounts was more
>> robust/paranoid in the face of concurrently whack-a-mole-dodging
>> entries.
> There is a trade-off here of possibly failing to detect after
> 1<<31 mods (old) versus a checksum collision (new). The latter seems
> slightly more robust. But it is even more paranoidically
> correct to combine them. Will do.
> For others: The issue is what to do in containsValue(v) when
> the map apparently does not contain v but has been changing
> while looking for it. This is surely uncommon but intrinsically
> expensive to deal with. The question is, at what point to you
> give up trying to traverse while the map is active and lock down
> the entire set of tables to force stability.
> -Doug

More information about the Concurrency-interest mailing list