[concurrency-interest] ConcurrentHashMap footprint and contention improvements

Doug Lea dl at cs.oswego.edu
Fri Apr 15 19:10:25 EDT 2011

On 04/15/11 14:16, Martin Buchholz wrote:
> 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

Yes, good point (this was also a problem with existing version).
This requires modCount updates on existing-put and replace.
Which together with other changes argue for again
relying solely on modCounts in containsValue. (Also, size()
is now slightly more prone to unnecessary retries but almost
surely not measurably.) These changes are now committed to CVS.

As another aside to other readers: Other j.u.c maps
do not make as strong a guarantee about the atomicity of
containsValue, and there is a good argument for not doing so.
However, we originally did it this way for ConcurrentHashMap,
and should not change it now; mainly because it is such a
rarely used method (and even rarer still used when value
is not present but table is undergoing modifications) that
it is not worth changing specs to allow it to run a bit
faster; especially since even at its fastest, it is still
intrinsically O(n).


More information about the Concurrency-interest mailing list