RFR (XS): CR 8006176: Switch to optimal identity hash code generator

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jan 23 11:20:36 PST 2013

On 01/23/2013 09:15 PM, Karen Kinnear wrote:
> Specifically, you need to test it with a wide range of benchmarks on a range
> of platforms.

Great, OK, I will do that internally.

> I will give you an example of why - we actually changed the hashcode we use
> internally in the vm (I believe it was the same change you just did, but I would
> have to search old sources in case it was a variation).  While the randomness
> in the general world was better - as you demonstrated - we ran into
> assertions in the vm because the lookup depth was worse. 

This does not sound right. Assertions failed because of the hashcode
randomness and collision rates? Do we really have these kind of
assertions? Sounds weird. It would be nice if you can give a pointer,

> So - let's work offline to ensure that this gets the level of performance testing
> necessary to vet this kind of change.

...Dave Dice also has a set of changes targeted on state transitions
when acquiring the hashCode, which we want to be pushed as well. If we
can see all the prior experience beforehand, we could make something
more thorough than just flipping the mode switch.


More information about the hotspot-runtime-dev mailing list