[infinispan-dev] Concurrent hashmaps parameters

David M. Lloyd david.lloyd at redhat.com
Tue Sep 15 13:42:12 EDT 2009


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.

- DML

On 09/15/2009 11:59 AM, Christian Vest Hansen wrote:
> Using NonBlockingHashMap from highscalelib could be another option.
> 
> On Tue, Sep 15, 2009 at 5:59 PM, Bela Ban <bban at redhat.com> wrote:
>> FYI,
>>
>> This might be important for you guys as well (if you haven't done so):
>> I'll add code to configure ConcurrentHashMaps based on system
>> properties, e.g. capacity, load factory etc.
>>
>> This will be important for large clusters. E.g. when we have 1000 nodes
>> in the cluster, most hashmaps in JGroups will contain 1000 entries, and
>> if we only have 16 buckets (the default IIRC), there would be a lot of
>> contention.
>>
>>
>> https://jira.jboss.org/jira/browse/JGRP-1049
>>
>> ConcurrentHashMap
>> -----------------
>>
>> CCHMs have a default initial capacity (16), load factor (0.75) and
>> concurrency level (16). These are OK for most
>> scenarios, but we have to investigate whether these values are
>> sufficient for 1000 node clusters.
>>
>> When for example 1000 threads from different senders access the same
>> CCHM, we need to make sure we don't have high
>> contention, ie. by spreading a 1000 senders over 16 buckets.
>>
>> Investigate whether we should add CCHM initial sizes, load factors and
>> concurrency levels as properties.
>>
>> With ergonomics [1], we could for example set bucket sizes for CCHMs
>> dynamically, e.g. based on cluster size.
>>
>>
>>
>> [1] https://jira.jboss.org/jira/browse/JGRP-1037
>>
>> --
>> Bela Ban
>> Lead JGroups / Clustering Team
>> JBoss
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> 
> 
> 



More information about the infinispan-dev mailing list