On 01/02/2013 10:20 AM, Alan Bateman wrote:
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.
String keys are treated specially in HashMap (using String.hash32()) and
don't need HashMap.hashSeed value at all. hashSeed is only used for
non-String keys. The question is why it has to be a unique value for
each individual HashMap instance? String.hash32() uses a once-per-JVM
allocated String.HASHING_SEED for example...
Regards, Peter
