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

[Karen Kinnear]

Aleksey,

So I appreciate your jumping in to look at this issue, and the tests that you
did run.

I strongly agree with David that this kind of change can not be made lightly.

Specifically, you need to test it with a wide range of benchmarks on a range
of platforms.

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. The point here is
that for the data set we were working on, the randomness was actually worse
and the real live performance of lookups (not hash generation) was worse.

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

thanks,
Karen

On Jan 14, 2013, at 5:39 PM, David Holmes wrote:

> On 14/01/2013 11:00 PM, Aleksey Shipilev wrote:
>> On 01/14/2013 04:53 PM, David Holmes wrote:
>>> This kind of switch can not be made lightly. It is not just a matter of
>>> raw performance, we have to understand how the change might affect
>>> existing applications. The default affects thousands of programs. A
>>> particular program can be run with -XX:hashCode=5 if it suits.
>> 
>> Agreed with the rationale; what should the appropriate test look like
>> for this kind of change?
> 
> At a minimum you would need to verify the performance of all the major performance apps across all platforms. But changes like this go beyond basic benchmarking.
> 
>> Disagreed with the conclusion: on these grounds we might as well do not
>> change the default behavior at all, frightened about all these
>> applications relying on subtleties they were never guaranteed to be
>> upheld. Having this in mind, I would say we should use most-performant
>> version, and let users to fallback to -XX:hashCode=0 if they identify
>> the problem with the new setting, which should be the red flag for their
>> applications anyway.
> 
> This is a naive view. Changing a default can only be done after a very careful analysis and consideration of a wide range of factors. Applications become dependent on non-guaranteed behaviour all the time without realizing it.
> 
> BTW also see 7161302.
> 
> David
> -----
> 
>> -Aleksey.
>>