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

[Aleksey Shipilev]

Hi Peter,

On 09/25/2014 02:46 AM, Peter Levart wrote:
>>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java

Interesting.

I have to say it once again:
 a) It is *an error* to use static finals as the benchmark input. They
are perfectly constant-foldable in way too many cases. Break this habit,
please.
 b) Explicit Blackholes are not needed, and just returning "int" from
@Benchmark method helps readability a lot. Please break this habit as
well. Having readable and maintainable benchmarks is a key.

>> This is really great!
>>
>> Couldn't this be a tweak via HotSpot, instead uglifying and bloating
>> the Java and hence the byte code?

+1

> 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...

I would think this happens in user-specified hashCode() over arrays.
IDEs would routinely inject the loop like that or delegate to
Arrays.hashCode, that does the same loop.

In other words, I would like to see this fixed on compiler side. This
seems to be the strength-reduction playing tricks with loop unrolling,
I'll submit a bug shortly.

-Aleksey.