ConcurrentHashMap segment resize threshold improvement

From email from Doug Lea:

From: Doug Lea <###@###.###>
Subject: Re: [concurrency-interest] ConcurrentHashMap use of
MAXIMUM_CAPACITY in Segment.rehash()

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
accordingly.

-Doug