Panama foreign on AArch64?

[Jorn Vernee]

Maurizio Cimadamore schreef op 2019-02-19 12:39:
> Hi Nick,
> overall, the ABI interface is relatively stable:
> 
> http://hg.openjdk.java.net/panama/dev/file/6b1f1666f5f6/src/java.base/share/classes/jdk/internal/foreign/abi/SystemABI.java
> 
> This is the interface used by the Panama binder for all
> system-specific stuff - it is conceptually easy, in that it takes a
> description of a function (e.g. native layouts, Java carriers) and
> return a MethodHandle that the client can use to make the call. A
> similar strategy is used for creating callbacks.
> 
> Panama supports two ABI implementation for now:
> 
> * SysVABI (Linux):
> http://hg.openjdk.java.net/panama/dev/file/6b1f1666f5f6/src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64ABI.java
> 
> * Windows ABI:
> http://hg.openjdk.java.net/panama/dev/file/6b1f1666f5f6/src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64ABI.java
> 
> Within each ABI implementation, there is a certain degree of freedom
> on how the method handles are generated - for instance, Linux supports
> two MH strategies: universal and direct invoker; Windows has only the
> universal invoker one.
> 
> We are also working on an alternate backend, called linkToNative -
> which will eventually obsolete the Linux direct invoker - and make
> these optimizations more portable across the board.
> 
> So, if you are looking to add ARM support, I'd suggest looking at
> what's been done for Windows: that is port the universal
> invoker/upcall implementation to ARM - that should be enough to be
> able to run the binder on ARM. When, in the future, linkToNative will
> land on the main 'foreign' branch, some tweaks will probably be needed
> in order to adjust the linkToNative logic to ARM - but looking at the
> work done for Windows by Jorn [1, 2], these adjustments seem to be
> rather small.

The changes were small because everything is mostly the same between the 
SysV and Windows ABIs, so I only had to insert some compiler switches 
with code to handle the Windows quirks. I'm not really well-versed in 
the AArach64 architecture or ABI, but at least the build system keeps 
x86 and AArach64 separate, so the changes will probably be a little more 
extensive to make another architecture work.

I would suggest starting with the 
UniversalNativeInoker/UniversalUpcallHandler backend, since that is 
broadly applicable, and has a little more debug code written for it 
already. It's also not certain the Direct backend would work for 
AArach64, since it relies on a SysV ABI trait, that for instance doesn't 
exist in the Windows ABI.

You could start by looking at 
src/hotspot/share/prims/universalNativeInvoker.cpp and 
src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp and try to replicate 
the functionality in the latter for AArach64.

On the Java side you'd have to start probably by looking at one of the 
src/java.base/share/classes/jdk/internal/foreign/abi/x64/<impl> folders, 
and replicating the functionality for AArach64. Generally, anything in 
the jdk.internal.foreign.abi package should be interesting to look at 
for a port.

The idea of UniversalNativeInvoker is that we stack all the unboxed 
arguments into a long[], and then provide a shuffle recipe to put these 
arguments into registers on the native side. The shuffle recipe is 
derived from a CallingSequence, which is generated internally by the 
particular ABI implementations.

The idea of UniversalUpcallHandler is that we create a native stub that 
forwards it's arguments as pointers to a java function, then give the 
native code a pointer to the generated stub. On the java side arguments 
are boxed from these pointer, and a target MethodHandle is called.

Cheers,
Jorn

> Let me know if you need extra pointers. I think this would be a very
> valuable experiment, as it might point out areas where we made
> incorrect, platform-dependent assumptions.
> 
> Cheers
> Maurizio
> 
> 
> [1] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2019-February/004271.html
> [2] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2019-February/004199.html
> 
> 
> On 19/02/2019 07:54, Nick Gasson (Arm Technology China) wrote:
>> Hi,
>> 
>> The panama foreign branch currently only has an implementation for 
>> x86.
>> Is anyone working on or planning to work on an AArch64 port? If not, 
>> is
>> this something we (Arm) could usefully contribute to now, or would it 
>> be
>> better to wait until the architecture-specific interfaces are more
>> finalised?
>> 
>> Thanks,
>> Nick