[infinispan-dev] Concurrent hashmaps parameters

Manik Surtani manik at jboss.org
Thu Sep 24 12:51:37 EDT 2009


On 24 Sep 2009, at 12:32, Manik Surtani wrote:

>
> On 16 Sep 2009, at 14:25, Mircea Markus wrote:
>
>>
>> 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.
>
> Correct that this correlation between concurrency level and data  
> container sizing is not there.  The CL is only used to tune the  
> number of lock stripes in the LockManager.  All 3 container impls  
> (SimpleDataContainer which uses CHMs and the FIFO/LRU containers  
> that use custom concurrent map impls) could benefit from this.  Will  
> create a JIRA to track this.

https://jira.jboss.org/jira/browse/ISPN-198


--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list