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.
