RFR: 8257882: Implement linkToNative intrinsic on AArch64 [v2]

Nick Gasson ngasson at openjdk.java.net
Thu Dec 10 09:15:50 UTC 2020


On Wed, 9 Dec 2020 09:58:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/aarch64/aarch64.ad line 16057:
> 
>> 16055: 
>> 16056:   format %{ "CALL, native $meth" %}
>> 16057: 
> 
> It might be better to expand this a little to indicate a near or a far call, if that's possible.

That would be nice but I can't see how to do it: adlc doesn't allow arbitrary code inside `format %{ %}`.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3186:
> 
>> 3184:     // Make sure that native code does not change SVE vector length.
>> 3185:     __ verify_sve_vector_length();
>> 3186:   }
> 
> Do we have to surround every call to verify_sve_vector_length() with if (UseSVE > 0) ?
> Why is that check not inside verify_sve_vector_length() ? What is the meaning of the
>> 0 comparison? Can it be negative? So many questions.  :-)

The valid values are {0,1,2} so > 0 is supposed to read as "SVE1 or SVE2". But I also think it's neater if the check is inside `verify_sve_vector_length` so I've moved it there.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3098:
> 
>> 3096:     MacroAssembler* masm = _masm;
>> 3097:     if (reg->is_Register()) {
>> 3098:       __ push(RegSet::of(reg->as_Register()), sp);
> 
> Is this right? SP is 16-aligned, so this will use 16 bytes of stack for every 8-byte register. Does it get used a lot?

It's used to preserve the native result registers around the runtime calls in the safepoint and reguard slow paths. With the way the intrinsic works currently, there'll actually only ever be a single output register. I did it this way originally to keep the code similar to x86 but actually it's just as easy to build a `RegSet` directly and push that, so I've removed these functions.

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

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


More information about the core-libs-dev mailing list