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

[Peter Levart]

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.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8006593/3/webrev/
>>
>> Once review is completed here this patch will be proposed to JDK7u-dev for integration into the next 7u performance/feature release.
>>
>> Mike
>>
>