[concurrency-interest] computeIfAbsent optimized for missing entries

Benjamin Manes ben.manes at gmail.com
Wed Feb 8 12:22:37 EST 2017


In JDK9, it looks like you added a small prescreening
<http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?r1=1.295&r2=1.296>
to
check at the first node in the bin and eagerly return. That seems like a
smart compromise, given the performance analysis you shared on this forum
previously that dissuaded you from adopting a full pre-screening.

On Wed, Feb 8, 2017 at 8:55 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 02/08/2017 01:52 AM, Amir Hadadi wrote:
>
>> I read the source code for ConcurrentHashMap's computeIfAbsent, and I
>> noticed it enters a synchronized block whether or not the key is present.
>>
>
> computeIfAbsent must be more conservative than putIfAbsent because
> we guarantee exclusion during the "compute" part.
> Even if an element is apparently present, we need to guarantee
> that it is not in the process of being removed (while holding lock).
>
> There was a fair amount of pre-jdk8 discussion about whether to
> guarantee locking/exclusion in CHM (it is not guaranteed for
> ConcurrentMaps in general). The consensus was that it was
> worth doing despite the extra overhead. Especially since it
> is avoidable in cases where you know that a key will never be
> removed once added, first calling get(), and then only
> call computeIfAbsent if it returns null.
>
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170208/3a12bf43/attachment.html>


More information about the Concurrency-interest mailing list