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

[Peter Levart]

On 09/24/2014 11:40 PM, Ulf Zibis wrote:
>
> 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?

This is for HotSpot compiler guys to answer. Theoretically I think it is 
possible. But it would have to be tailored to the very specific use case 
and I don't know if such specific transformation would have wide-enough 
applicability. If it would only speed-up String.hashCode and very 
similar loops, it is less trouble to do that by hand in one or few 
places...

Regards, Peter


>
> -Ulf
>