Scaling problem of HashMap (introduced with alternative hashing)

[Aleksey Shipilev]

Seriously doubt Android uses (recent) OpenJDK HashMap code, otherwise many lawyers around the world would now be having heart attacks. Also, java.util.Random is plain congruent PRNG, having nothing to do with entropy pools, preseeded with nanoTime() at most.

-Aleksey.

On 07.01.2013, at 16:19, Alexey Utkin <alexey.utkin at oracle.com> wrote:

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