Re: AtomicReferenceArray.get() and intrinsics method inlining

@manuel and attempts to use JMH too! :P

Il gio 16 gen 2020, 22:09 Manuel Dominguez Sarmiento via
Concurrency-interest <[email protected]> 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
> 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
> <[email protected]> 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
>> [email protected]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest