[concurrency-interest] AtomicReferenceArray.get() and intrinsics method inlining
ben.manes at gmail.com
Thu Jan 16 15:38:39 EST 2020
I have not investigated Ehcache 2.x for a while, but it used to
use SelectableConcurrentHashMap  which is a fork of Java 5's map. In
that fork, the lock-free reads is replaced by a per-segment read lock.
At the time of 2.10.4, this was the default implementation when creating a
cache in a benchmark  as,
CacheConfiguration config = new CacheConfiguration("benchmark",
cache = new Cache(config);
That JMH benchmark ran with a Zipfian distribution (so hot keys are
accessed more frequently) and I observed ~20M gets per second at 16 cores,
using the LRU policy.
The benchmark might be a good starting point. I had to remove v2 when it
became incompatible with v3 due to .
This was applicable around 2014-15 timeframe and I have not looked at it
since, so beware of my possible misunderstandings.
On Thu, Jan 16, 2020 at 12:36 PM Aleksey Shipilev via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:
> On 1/16/20 9:28 PM, Manuel Dominguez Sarmiento wrote:
> > We used Oracle JDK 1.8.0_212 on Mac OS X to produce the reported
> results. Update 212 is from April
> > 2019 so it's not that old anyway.
> Wait, now *that* sounds familiar.
> Plus the original observation:
> > After careful studying of stock Java8 ConcurrentHashMap.get(), we found
> that the reason why that
> > method was being successfully inlined is the (tab = table) != null
> check before tabAt() is
> > invoked. Apparently, the HotSpot compiler is unable to inline
> getObjectVolatile() unless it can
> > verify thatits main argument will always be non-null.
> Suggests this:
> You should really try up-to-date JDK.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest