[concurrency-interest] AtomicReferenceArray.get() and intrinsics method inlining

Manuel Dominguez Sarmiento mads at renxo.com
Thu Jan 16 16:09:03 EST 2020


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 
java.util.concurrent.ConcurrentHashMap

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 [1] 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 [2] as,
>     CacheConfiguration config = new CacheConfiguration("benchmark", 
> maximumSize);
> config.setMemoryStoreEvictionPolicyFromObject(evictionPolicy);
>     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 [3].
>
> This was applicable around 2014-15 timeframe and I have not looked at 
> it since, so beware of my possible misunderstandings.
>
> [1] 
> http://svn.terracotta.org/svn/ehcache/trunk/ehcache/ehcache-core/src/main/java/net/sf/ehcache/store/chm/SelectableConcurrentHashMap.java
> [2] 
> https://github.com/ben-manes/caffeine/blob/master/caffeine/src/jmh/java/com/github/benmanes/caffeine/cache/GetPutBenchmark.java
> [3] 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 
> <mailto: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:
>     https://bugs.openjdk.java.net/browse/JDK-8221355
>
>     You should really try up-to-date JDK.
>
>     -- 
>     Thanks,
>     -Aleksey
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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/20200116/3c34ff17/attachment.htm>


More information about the Concurrency-interest mailing list