RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

[Ulf Zibis]

Am 24.09.2014 um 22:25 schrieb Peter Levart:
> Hi,
>
> String.hashCode() caches the result, so repeatable call to same String instance is faster for 2nd 
> and further invocations. But the computation of hash code itself could be accelerated for a factor 
> of 2 or more on todays CPUs. How? By parallelizing it. And I don't mean computing it in multiple 
> threads.
>
> Here is a surprising result of a simple benchmark which computes hash code of a 128 character 
> string in 6 different ways:
>
> Benchmark                    Mode   Samples        Score  Score error    Units
> j.t.HashBench.hashCode      thrpt         8  8420103.795 162447.069    ops/s
> j.t.HashBench.hashCode0     thrpt         8  8439058.660 2842.755    ops/s
> j.t.HashBench.hashCode1     thrpt         8 13809510.573 337888.132    ops/s
> j.t.HashBench.hashCode2     thrpt         8 15543687.568 716152.160    ops/s
> j.t.HashBench.hashCode3     thrpt         8 18173224.431 49410.256    ops/s
> j.t.HashBench.hashCode3x    thrpt         8  8543020.232 18158.686    ops/s
>
>
> Source:
>
> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java

This is really great!

Couldn't this be a tweak via HotSpot, instead uglifying and bloating the Java and hence the byte code?

-Ulf