[foreign-memaccess+abi] RFR: 8274912: Eagerly generate native invokers

Jorn Vernee jvernee at openjdk.java.net
Thu Oct 7 15:28:29 UTC 2021


On Thu, 7 Oct 2021 15:06:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> 
>> This patch is a refactoring of VM code pertaining to downcalls. As outlined in the JBS issue, this patch makes 'native invoker' generation currently done by C2 eager.
>> 
>> Most of the changes in this patch are moving around existing code:
>> - The native invoker generation code is moved from sharedRuntime*.cpp to universalNativeInvoker*.cpp, to match what is done for upcalls.
>> - C2 & nmethod scaffolding for registering native invokers has been removed (lifetime is now managed in Java code).
>> - Now, C2 will only intrinsify trivial downcalls, which means some of the code was simplified there.
>> - To reduce code duplication, several utilities have been added:
>>   - ArgumentShuffle (and impls of CallConvClosure): a utility class for computing argument shuffles and generating shuffling code. The shuffling code is heavily based on what is done today for optimized upcalls on x64.
>>   - To support the above, I've made a copy of the ComputeMoveOrder utility from SharedRuntime code (which was only implemented on x64), and adapted it to our use case.
>>   - RegSpillFill: similarly, a utility for computing and generating register spill and fill code (given a list of registers).
>>   - oop_cast: this was a pre-existing utility that was renamed (from 'cast') and moved into a separate file.
>> - The linkToNative method handle intrinsic now just loads the invoker address from the appendix argument and jumps to it, instead of jumping to the fallback method handle.
>> 
>> The implementation passes all the jdk_foreign tests on Windows/x64, Linux/x64 (WSL), and Linux/AArch64. Though, there were some pre-exsiting test failures on AArch64 wrt variadic functions.
>> 
>> Thanks,
>> Jorn
>
> src/hotspot/cpu/arm/universalNativeInvoker_arm.cpp line 33:
> 
>> 31: }
>> 32: 
>> 33: RuntimeStub* ProgrammableInvoker::make_native_invoker(BasicType* signature,
> 
> Maybe crazy idea - can we make it so that, by default make_native_invoker will just throw Unimplemented() in the ProgrammableInvoker class - and if clients want to provide implementation for it, they have to subclass and define an implementation? This might avoid need for stubbing things out.

Well, I guess in that case each platform would still need to define a factory method for the platform specific impl, so that platform agnostic code can reach it, and that would then need to be stubbed on unsupported platforms.

But, either way, I think it's better to stick with the conventions used in other VM code, which is to stub things out.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/593


More information about the panama-dev mailing list