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