[infinispan-dev] Eviction maxEntries analysis

[Mircea Markus]

That was my understanding as well.

----- Original Message -----
From: "Galder Zamarreño" <galder at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Monday, February 6, 2012 9:57:20 AM
Subject: Re: [infinispan-dev] Eviction maxEntries analysis

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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev