RFR: 8282664: Unroll by hand StringUTF16, StringLatin1, and Arrays polynomial hash loops [v2]

[Ludovic Henry]

On Tue, 8 Mar 2022 17:07:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. Thanks.
>> 
>> Yes, it's troubling that making a constant non-foldable can lead the JIT down a path that ultimately pessimizes the end result (as observed here). If we could train the JIT to avoid this pitfall and get to the improvement observed in my experiment here without any changes to `String.java` then that'd be great.
>
>> @cl4es Yes, we would need to carefully measure the impact for small array sizes (similar to what we had to do when the array mismatch intrinsic was implemented and applied to array equals). My sense is to focus on the intrinsic and also look for potential opportunities like @merykitty points out, as that is where the larger impact is, although it is more work!
> 
> Right, I'm not too thrilled about the prospect of moving ahead with the de-constantification as an alternative patch here. It's such a crutch, but it's also simple and has no obvious downsides as of right now. I think it was a useful experiment to see where some of the gain observed in the unroll might be coming from. The degradation on many smaller `Strings` in the unrolled versions is a concern that I think might be a blocker, though. Short Strings are excessively common as keys in hash maps et.c.. 
> 
> Feels like none of the alternatives seen here so far is really _it_.

@cl4es that was indeed the issue leading to the crash. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700