RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13]

[Claes Redestad]

On Sat, 12 Nov 2022 01:10:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 12081:
>> 
>>> 12079:   format %{ "Array HashCode byte[] $ary1,$cnt1 -> $result   // KILL all" %}
>>> 12080:   ins_encode %{
>>> 12081:     __ arrays_hashcode($ary1$$Register, $cnt1$$Register, $result$$Register,
>> 
>> What's the motivation to keep the stub code inlined instead of calling into a stand-alone pre-generated version of the stub?
>
> Also, switching to stand-alone stubs would enable us to compose a generic stub version (as we do in `StubGenerator::generate_generic_copy()` for arraycopy stubs).  But it would be even better to do the dispatching on JDK side and always pass a constant into the intrinsic.

There are no single reason this code evolved the way it did. @luhenry worked on it initially and was guided towards intrinsifying what was originally a JDK-level unrolling. Then I took over and have tried to find a path of least resistance from there. @luhenry have discussed rewriting part or all of this as a stub, for various reasons. I've been scoping that out, but with no experience writing stub versions I figured perhaps this could be done in a follow-up. If you think there's a compelling enough reason to rewrite this as a stub up front I can try and find the time to do so.

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

PR: https://git.openjdk.org/jdk/pull/10847