[concurrency-interest] ConcurrentHashMapV8

Jason T. Greene jason.greene at redhat.com
Fri Sep 30 12:58:26 EDT 2011

On 9/8/11 6:45 AM, Doug Lea wrote:
> Among some further ongoing improvements and extensions (mainly
> to support parallel aggregate operations), I'm contemplating
> (nearly) ignoring "loadFactor" constructor arguments for
> ConcurrentHashMap (in "V8" form for now, but ultimately
> targeting revised j.u.c version). The main motivation
> is that in concurrent hash maps (of any form) collisions
> and contention are interdependent, so anyone using a
> higher-than-default load factor because they think it will
> save space is also unexpectedly getting poorer multithreaded
> performance. Given how hard it was to give clear answers to
> questions on this list about exactly what blocks when based on
> probability distributions with a parameter based on load factor,
> I'm now thinking that is best to internally always use
> the default, and use the optional constructor parameter
> only as an initial sizing hint (larger loadFactor ->
> smaller initial capacity). This will enable simpler
> characterization of expected performance.
> Scanning for uses of ConcurrentHashMap constructors
> on google code search, it seems that hardly anyone ever
> overrides the default anyway, so this probably doesn't
> matter much either way. But if you have ever done so,
> and have a good reason, could you let me know? Thanks!

What about just limiting the upper range? I could see someone dropping 
the default load factor to get marginally better throughput.

Although, IMO the only must-have scenario for exposing a load factor is 
if you have an open addressed map and the factor heavily affects access 

Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat

More information about the Concurrency-interest mailing list