[concurrency-interest] ConcurrentHashMapV8

Doug Lea dl at cs.oswego.edu
Fri Sep 9 09:06:24 EDT 2011


Thanks as always for the on- and off-list feedback.
It seems worthwhile to simplify use and documentation of
load factors, so the current update does so.


On 09/08/11 12:10, Alex Miller wrote:
> I think the only time I have ever seen someone use an alternate load
> factor is in the case where they are creating a Map that has a known
> maximum fixed size and they want to ensure that the map will never
> need to rehash.  It might be helpful to specify in Javadoc how to
> achieve that goal.
>

Yes, thanks. The answer should be utterly obvious:
Use the constructor with this fixed size as the initialCapacity.

Unfortunately, the existing j.u.c specs and javadocs made this
confusing; and worse, not absolutely guaranteed to be true.
Some of the confusion was due to the unintended
implication that the default constructor is sized to hold 16
elements, when instead it is just 16 period.
In practice, most of the slop doesn't matter at all.
With power of two tables, there are only 30 possible
table sizes, so calculations based on misunderstandings
about the meaning of constructor parameters usually end up
to be what people expect anyway. But still it should be,
and now is, straightened out.

> On 09/08/11 18:16, dhanji at gmail.com wrote:
>> I think this is a reasonable position for loadFactors > default. But perhaps not
>> lower.
>>

The adjustment works both ways, but only for initial
sizing, which is the only aspect that is fully controllable
in a concurrent table. So if you'd like an extremely sparsely
populated table for say 1000 elements, you can use
   new ConcurrentHashMap(1000, 0.25f);
The only difference from existing j.u.c version is that if you
don't have a good size estimate, and want it sparsely
populated anyway, we can't help you. But we could never exactly
promise this anyway; among other reasons because sizes may fluctuate
while resizing is in progress.

So little actual control is lost, and we gain a more understandable
characterization in the revised constructor and class-level javadocs.
The class-level now includes just barely enough background on
hashing to clearly explain what's up without making people plod through
Too Much Information. I hope. See:
http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/ConcurrentHashMapV8.html

-Doug








More information about the Concurrency-interest mailing list