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.
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org