Scaling problem of HashMap (introduced with alternative hashing)

[Remi Forax]

On 01/07/2013 01:19 PM, Alexey Utkin 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/

Not sure there is a real problem here, if you wake up the CPU of your 
smartphone often you have better performance (and less battery), paying 
an application for that is a scam. Anyway, it's related to android 
kernel/ecosystem so not applicable here.

The issue here is that SecureRandom use a lock so if you create a lot of 
HashMap in a tight loop you can see a regression. I don't think it 
impact real application and as Mike said, using a ThreadLocalRandom 
seems a good idea here (no idea if it's secure to use it) .

>
> Regards,
> -uta

cheers,
Rémi

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