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

[David Holmes]

Aleksey,

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.

David
-----

On 14/01/2013 9:55 PM, Aleksey Shipilev wrote:
> Hi,
>
> This is a simple issue reported by one of our customers, relying heavily
> on System.identityHashCode(...) in their code. They figured out the
> global state in current identity hashcode generator penalizes
> scalability. Their workaround is to switch -XX:hashCode=5 to the
> thread-local Marsaglia's XorShift generator.
>
> The motivation is really simple when the targeted microbenchmark is
> considered: asking System.identityHashCode(new Object()) continuously in
> multiple threads.
>
> On 2x2 Intel i5-2520M, Linux x86_64, JDK 7u12-ea:
>
> 1 thread:
> -XX:hashCode=0: 11.3 +- 0.9 ops/usec
> -XX:hashCode=1: 12.3 +- 0.3 ops/usec
> -XX:hashCode=2: 12.8 +- 0.2 ops/usec
> -XX:hashCode=3: 11.7 +- 0.1 ops/usec
> -XX:hashCode=4: 12.5 +- 0.1 ops/usec
> -XX:hashCode=5: 12.1 +- 0.2 ops/usec
>
> 4 threads:
> -XX:hashCode=0: 19.3 +- 0.1 ops/usec
> -XX:hashCode=1: 25.5 +- 0.3 ops/usec
> -XX:hashCode=2: 26.8 +- 0.1 ops/usec
> -XX:hashCode=3: 20.8 +- 0.1 ops/usec
> -XX:hashCode=4: 25.1 +- 0.5 ops/usec
> -XX:hashCode=5: 24.9 +- 0.2 ops/usec
>
> So, even on this small machine, the scalability improvement is very
> telling 19.3 ->  24.9 ops/usec.
>
> On 2x8x2 SandyBridge box, JDK8 HEAD:
>
> 1 thread:
> -XX:hashCode=0: 16.9 +- 0.5 ops/usec
> -XX:hashCode=1: 19.2 +- 0.1 ops/usec
> -XX:hashCode=2: 18.9 +- 0.3 ops/usec
> -XX:hashCode=3: 18.9 +- 0.4 ops/usec
> -XX:hashCode=4: 19.0 +- 0.1 ops/usec
> -XX:hashCode=5: 18.5 +- 0.3 ops/usec
>
> 32 threads:
> -XX:hashCode=0: 10.7 +- 0.1 ops/usec
> -XX:hashCode=1: 175.2 +- 4.9 ops/usec
> -XX:hashCode=2: 184.8 +- 3.7 ops/usec
> -XX:hashCode=3: 14.2 +- 0.1 ops/usec
> -XX:hashCode=4: 160.0 +- 2.6 ops/usec
> -XX:hashCode=5: 176.6 +- 6.0 ops/usec
>
> Note whooping scalability increase when dealing with non-shared generators.
>
> Randomicity is another concern, and our internal tests show that
> thread-local PRNG (mode 5) is as good as the global PRNG (mode 0), you
> can see that here:
>   http://cr.openjdk.java.net/~shade/8006176/randomicity/
>
> It turns out that modes 0, 2, and 5 are random enough; and mode 5 is the
> most scalable one. Hence, we'd like to switch to mode 5, here's the webrev:
>   http://cr.openjdk.java.net/~shade/8006176/webrev.00/
>
> Thanks,
> -Aleksey.
>