[infinispan-dev] Concurrent hashmaps parameters

[Mircea Markus]

On Sep 16, 2009, at 10:22 AM, Jason T. Greene wrote:

> Bela Ban wrote:
>>
>> David M. Lloyd wrote:
>>> NonBlockingHashMap is great *except* that it relies on  
>>> sun.misc.Unsafe,
>>> which makes portability a bit iffy. I *think* that it could be  
>>> ported to
>>> use Atomic* instead, but it looked like quite a bit of work to do  
>>> so (not
>>> to mention testing).
>>>
>>> The problem with CHM is that they are *big*, so you don't want to  
>>> have a
>>> lot of them - *especially* if you're using a high concurrency level,
>>> because they get even bigger in that case.
>>
>> Understood that CHMs are big, but back to my question: how doesn
>> Infinispan intend to address hashmaps with 1000 different keys ? Or  
>> are
>> you guys already parameterizing creation of CHMs ?
>>
>
> There is a concurrency level setting that the user can set based off  
> of
> expected size (it also affects striping).
I think this only has to do with the lock striping, and is rather  
related to the number of concurrent users expected to access the  
cache, not with the size of the data.
AFAIK, there's no correlation between the number of cache entries, and  
the way the CHMs are being instantiated. Manik can put some more light  
on this on his return, but I do see a lot of sense for this correlation.
> -- 
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev