PR: https://github.com/infinispan/jdg/pull/536

Hi, I don't know whether it is a good idea to put a fix with 10000+ lines of code, which re-implemenents the whole logic of eviction, into a micro release.

Hi,
behaviour of BoundedEquivalentConcurrentHashMapV8StressTest seems to be little bit weird. For 1M of entries run smoothly, but for 10M with eviction strategy on fills the map forever (forever == 45min on my machine and then I gave up). I.e. for 10M of entries and more BoundedEquivalentConcurrentHashMapV8 seems unusable. Bellow is part of the stack trace.

Will, could you please comment on that? Is this expected or any hint where could be the problem? (I had enough memory available, the process consumed 2 cores)

Thanks



Thread 4182: (state = BLOCKED)
 - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LRUEvictionPolicy.createNewEntry(java.lang.Object, int, org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$Node, java.lang.Object, org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$EvictionEntry) @bci=28, line=519 (Compiled frame)
 - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.putVal(java.lang.Object, java.lang.Object, boolean) @bci=94, line=2406 (Compiled frame)
 - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.put(java.lang.Object, java.lang.Object) @bci=4, line=2393 (Compiled frame)
 - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8StressTest.testRemovePerformance(int, java.util.Map, java.lang.String) @bci=74, line=35 (Compiled frame)
 - org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8StressTest.testLRURemovePerformance() @bci=33, line=82 (Interpreted frame)

Vojtech,

Just to clarify I am guessing you meant LRU eviction strategy (looking at the stack trace it seems to be) ?   I am guessing this also affected LIRS ?

Also do you happen to have the entire JVM stack trace ?  The snippet here seems to be fine from what I can see.

Also it seems you are using BoundedEquivalentConcurrentHashMapV8StressTest to test this?  Is that correct ?  I have run it quite a few times with 10M and haven't had an issue yet, the stack trace should help immensely.

Sorry for the false alarm, it was caused by GC and misconfiguration of my JAVA heap (I setup bigger heap for maven itself instead of surefire forked process). Now everything runs smooth and new implementation is noticeably faster then the old one.