Re: [infinispan-dev] Concurrent hashmaps parameters

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.