RFR: 8006593: Performance and compatibility improvements to hash based Map implementations

[Mike Duigou]

After looking more closely at the single read reference to hashSeed I decided to simplify things and make hashSeed non-final in both Hashtable and HashMap.

I've posted a refreshed webrev. 

http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/

Mike

On Mar 4 2013, at 14:25 , Peter Levart wrote:

> 
> On 03/04/2013 11:14 PM, Peter Levart wrote:
>> Hi mike,
>> 
>> I doubt (haven't tried it really with your code) that hashSeed will be seen by code to be anything else but 0, since it is initialized to a constant value. For example, this code:
>> 
>> public class ModifyingFinalTest {
>>     static final Unsafe unsafe;
>>     static final long valueOffset;
>> 
>>     static {
>>         try {
>>             Field f = Unsafe.class.getDeclaredField("theUnsafe");
>>             f.setAccessible(true);
>>             unsafe = (Unsafe)f.get(null);
>>             valueOffset = unsafe.objectFieldOffset(ModifyingFinalTest.class.getDeclaredField("value"));
>>         }
>>         catch (IllegalAccessException | NoSuchFieldException e) {
>>             throw new Error(e);
>>         }
>>     }
>> 
>>     final int value = 0;
>> 
>>     void test() {
>>         unsafe.putIntVolatile(this, valueOffset, 1);
>>         printValue();
>>         unsafe.putIntVolatile(this, valueOffset, 2);
>>         printValue();
>>         unsafe.putIntVolatile(this, valueOffset, 3);
>>         printValue();
>>     }
>> 
>>     void printValue() {
>>         System.out.println(value);
>>     }
>> 
>>     public static void main(String[] args) {
>>         new ModifyingFinalTest().test();
>>     }
>> }
>> 
>> 
>> Prints:
>> 
>> 0
>> 0
>> 0
>> 
>> 
>> It's a different thing, if the initialization is changed to:
>> 
>> final int value = "".length();
>> 
>> But I don't know if each access in source is actually guaranteed to translate to a real read of field in this case either. Is Unsafe.putIntVolatile() making this happen somehow magically?
> 
> Well, that's not what I wanted to ask. I wanted to ask if the first access in source that happens after Unsafe.putIntVolatile() in same thread is guaranteed to read the field and not re-use a cached value ready in some register for example. Is Unsafe.putIntVolatile() making this happen somehow magically?
> 
>> 
>> Regards, Peter
>> 
>> 
>> On 03/04/2013 09:21 PM, Mike Duigou wrote:
>>> Hello all;
>>> 
>>> The alternative hashing implementation introduced in 7u6 added an unfortunate bottleneck to the initialization of HashMap and Hashtable instances. This patch avoids the performance bottleneck of using a shared Random instance by using a ThreadLocalRandom instead.
>>> 
>>> Along with this change are some additional performance improvements to further reduce the overhead of the alternative hashing feature and generally improve the performance of Hashtable or HashMap.
>>> 
>>> c
>>> 
>>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release.
>>> 
>>> Mike
>>> 
>> 
>