[concurrency-interest] AtomicReferenceArray.get() and intrinsics method inlining
nigro.fra at gmail.com
Thu Jan 16 16:52:50 EST 2020
@manuel and attempts to use JMH too! :P
Il gio 16 gen 2020, 22:09 Manuel Dominguez Sarmiento via
Concurrency-interest <concurrency-interest at cs.oswego.edu> ha scritto:
> Hi Ben, thanks to your comment, we found an issue in some critical
> interning and reflection-related classes in our codebase: they were using
> net.sf.ehcache.util.concurrent.ConcurrentHashMap instead of
> It seems Eclipse's auto-import feature picked the "wrong"
> ConcurrentHashMap ... so that's why we're seeing the
> net.sf.ehcache.util.concurrent.ConcurrentHashMap in our profiler even if
> it's not the default map EhCache might be using for the actual caches.
> Lessons learned: always use an up-to-date JDK and never trust Eclipse's
> auto-import feature.
> 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.
>  https://github.com/ehcache/ehcache3/issues/2334
> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest