RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
aleksey.shipilev at oracle.com
Thu Sep 25 07:40:03 UTC 2014
On 09/25/2014 02:46 AM, Peter Levart wrote:
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,
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?
> 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
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.
More information about the core-libs-dev