Scaling problem of HashMap (introduced with alternative hashing)

[Alexey Utkin]

I am sorry. Seems that I am out of discussion context, but did we get 
that sort of problem:

https://code.google.com/p/android/issues/detail?id=42265#c114
http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0

The article in Russian:
http://habrahabr.ru/post/164881/

Regards,
-uta

On 27.12.2012 23:55, Mike Duigou 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