Scaling problem of HashMap (introduced with alternative hashing) (original) (raw)
Alexey Utkin alexey.utkin at oracle.com
Mon Jan 7 12:19:45 UTC 2013
- Previous message: Scaling problem of HashMap (introduced with alternative hashing)
- Next message: Scaling problem of HashMap (introduced with alternative hashing)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Scaling problem of HashMap (introduced with alternative hashing)
- Next message: Scaling problem of HashMap (introduced with alternative hashing)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]