Scaling problem of HashMap (introduced with alternative hashing) (original) (raw)
Alan Bateman Alan.Bateman at oracle.com
Wed Jan 2 09:20:41 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 ]
On 01/01/2013 23:13, Eric McCorkle wrote:
Was the original purpose security-oriented? It seemed to me that the purpose was to make performance pathologies less likely.
Consider, for example, a bad hash function that maps ip addresses directly to their integer representation. If an application puts entire subnets into a map. All the addresses will go into contiguous buckets, which increases probability of a collision considerably. Adding in randomness helps to smooth over these sorts of pathologies. It was related to collisions, particularly where the keys are Strings and coming from an untrusted source. There are better solutions for handling a huge number of collisions now and we need to change this code (ie: get rid of the alternative hashing). For jdk7u then we have to be more cautious and I think Mike is going to see about changing it to use ThreadLocalRandom.
-Alan.
- 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 ]