On Sat, 12 Nov 2022 01:10:50 GMT, Vladimir Ivanov <vliva...@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
