[infinispan-dev] Eviction maxEntries analysis

[Manik Surtani]

As Mircea said, just create an FAQ with a link to the bug ID in the IBM JDK and reject the Infinispan bug. :)

On 7 Feb 2012, at 15:03, Martin Gencur wrote:

> On Mon, 2012-02-06 at 06:22 -0500, Mircea Markus wrote:
>> That was my understanding as well.
> 
> Yeah, the first number is for LRU. I initially encountered this behavior
> with EDG so I tried also with ISPN and created
> https://issues.jboss.org/browse/ISPN-1822 . I was about to close it as
> "Rejected" or so but now I don't know:)
> 
> The fact is that there will be rarely such a use case with just a few
> entries in a cache. So I don't know if this is worth investigating.
> 
> Martin
> 
>> 
>> ----- 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
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> -- 
> Martin Gencur
> --
> JBoss QE, Enterprise Data Grid
> Desk phone: +420 532 294 192, ext. 62192
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org