Vladimir, I had understood that with the new eviction logic, the only possible case is that the cache was evicted *before* maxEntries was reached cos eviction happened at the segment level.
However, I'd have never expected for the cache to grow beyon its size. If that's the case, I think that'd be a bug. @Martin, what I don't understand about the figures below is what algorithm is used with IBM JDK. Is that LRU and LIRS for the numbers in parenthesis? If so, maybe a bug in LRU with IBM JDKs? Cheers, On Feb 3, 2012, at 6:17 PM, Vladimir Blagojevic wrote: > Martin, > > There will always be "problems" around sizing in these small containers. > I think we are all aware of it now, what is more important is that > eviction works properly in all other scenarios! I am ok with this! > > Regards, > Vladimir > > On 12-02-03 11:59 AM, Martin Gencur wrote: >> I see, for the bigger numbers entries are evicted (more than just to >> decrease the number to maxEntries) before I actually check the number so >> this is expected. For the 2,4,6,8,10 eviction did not run so the cache >> contains more than maxEntries. Are we OK with that? >> >> Thanks >> >> >> M. >> >> >> On Fri, 2012-02-03 at 15:29 +0100, Martin Gencur wrote: >>> Hi all, >>> I ran a few tests to find out what is the actual number of entries held >>> in a cache when certain "maxEntries" param is set for eviction and I >>> store more than maxEntries entries. I tested with HotSpot JDK6 [1], IBM >>> JDK 6,7 [2]. OpenJDK6 seems to have the same results as HotSpot JDK. >>> >>> Results: >>> >>> maxEntries being set -> actual number of entries held in the cache >>> >>> HotSpot JDK: >>> ------------ >>> >>> 2 -> 2 >>> 4 -> 4 >>> 6 -> 4 >>> 8 -> 8 >>> 10 -> 8 >>> 256 -> 232 >>> 300 -> 266 >>> >>> IBM JDK (both 6, 7): >>> -------------------- >>> >>> 2 -> 4 (2 with LIRS) >>> 4 -> 6 (4 with LIRS) >>> 6 -> 10 >>> 8 -> 11 (8 with LIRS) >>> 10 -> 13, (8 with LIRS) >>> 300 -> 287, (266 with LIRS) >>> 256 -> 247, (232 with LIRS) >>> >>> I modified one test in ispn-core to do this testing: >>> https://github.com/mgencur/infinispan/commit/837a1c752fa7fbfb3f05738dd873e78cbf71d071 >>> >>> >>> >>> Any thoughts ? :) >>> >>> >>> >>> [1] >>> >>> java version "1.6.0_21" >>> Java(TM) SE Runtime Environment (build 1.6.0_21-b06) >>> Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) >>> >>> [2] >>> >>> java version "1.6.0" >>> Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 >>> FP1)) >>> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 >>> jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) >>> >>> java version "1.7.0" >>> Java(TM) SE Runtime Environment (build pxi3270-20110827_01) >>> IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT >>> enabled, AOT enabled) >>> >>> >>> > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
