Scaling problem of HashMap (introduced with alternative hashing)

[Aleksey Shipilev]

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.duigou at 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.yu at 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
>