From email 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
Posted Date : 2007-01-11 21:32:26.0

N/A

Like Doug said.
Posted Date : 2007-01-11 21:33:02.0