Transient HashMaps allocated on demand are actually quite often in user code. I think at large enough machine you will hit the coherence wall much sooner than the allocation wall. Pity I missed to review that code long before. Please let me know if you need help figuring out another solution.
-Aleksey. On 27.12.2012, at 23:55, Mike Duigou <mike.dui...@oracle.com> wrote: > I am responding on the StackOverflow thread. I will look into using > ThreadLocalRandom. > > The random.next() is clearly a potential bottleneck but given that this > happens only once per HashMap instance it is still unclear why a reasonable > application would want to create hundreds or thousands of hash maps per > second. > > Mike > > On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: > >> Looks very like dumb inlined java.util.Random? >> Is there a security threat to use ThreadLocalRandom instead there? >> >> -Aleksey. >> >> On 27.12.2012, at 23:16, Zhong Yu <zhong.j...@gmail.com> wrote: >> >>> Reported by the SO question >>> >>> http://stackoverflow.com/questions/14010906 >>> >>> the HashMap constructor contains a CAS, which is kind of surprising. >>> Could it be removed? >>> >>> transient final int hashSeed = >>> sun.misc.Hashing.randomHashSeed(this); // CAS >>> >>> Zhong Yu >
