[concurrency-interest] ConcurrentHashMap use of MAXIMUM_CAPACITY in Segment.rehash()

Doug Lea dl at cs.oswego.edu
Wed Jan 10 13:19:11 EST 2007

Rachel Suddeth wrote:
> I am looking at the rehash() method in the Segment
> inner class of ConcurrentHashMap. First thing it does
> is test for maximum size:
> ---
>    void rehash() {
>        HashEntry<K,V>[] oldTable = table;
>        int oldCapacity = oldTable.length;
>        if (oldCapacity >= MAXIMUM_CAPACITY)
>             return;
>        ...
> ---
> It seems odd to me that it's testing against the max
> number of bins for the whole ConcurrentHashMap when
> deciding to resize the segment table. (Is that not
> what MAXIMUM_CAPACITY represents?) Initial size for
> the segment table is (essentially)
> initialCapacity/concurrencyLevel. I would have
> expected the max for the segment to be calculated in a
> similar way. I thought (maybe this is wrong?) that
> certain bits of the Key's hash code were used to
> determine the segment, and the others would determine
> the bin within the segment, so that the full value of
> an int would not be usable as an index into the
> segment's table?
> Am I missing something?

MAXIMUM_CAPACITY is used just to avoid integer overflow
for index calculations. But you are right that a tighter
bound could be used here to also avoid unproductive growth of
segments. Thanks for the suggestion! We'll probably adjust


More information about the Concurrency-interest mailing list