Error during opening a native lib on Apple M1

[Maurizio Cimadamore]

Hi Clemens,
I believe you have run into a known limitation that Panama (and JNI) 
have when it comes to calls spilling arguments on stack on MacOs on M1:

https://bugs.openjdk.org/browse/JDK-8275584

In most systems, stack arguments are spilled at "slots" that are at 
multiple of a certain system size (e.g. 16 bytes).

But on MacOs/Aarch64 the stack arguments are "packed" and original 
alignment constraints are preserved. The hotspot code does not know, in 
JDK 19, how to deal with this scenario.

Work is under way to lift this restriction in Java 20:

https://github.com/openjdk/panama-foreign/pull/699

I believe the difference between 18 and 19 is that in 19 we added some 
logic to detect the problematic call shapes (as JNI does), whereas on 18 
the code just led to undefined behavior.

It is possible that your application never called this particular 
function - if that's the case I'd recommend filtering it out using 
jextract filtering options.

Maurizio


On 04/09/2022 18:13, Clemens Lanthaler wrote:
> Hello everyone,
>
> I have just ported over LibrawFX to JDK19 and have used the latest bin 
> release of jextract on OSX/win for porting it over to the JDK19 lang 
> features. The code is working under JDK18 (1.8.0 release branch).
>
> When I execute the new code under an Apple M1 I am getting always on 
> the init method / first call to the native lib the error message:
> java.lang.ExceptionInInitializerError: Exception 
> java.lang.UnsupportedOperationException: Call type not supported on 
> this platform [in thread "Thread-6"]
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.stackAlloc(CallArranger.java:206)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.stackAlloc(CallArranger.java:217)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$StorageCalculator.nextStorage(CallArranger.java:244)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger$UnboxBindingCalculator.getBindings(CallArranger.java:395)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger.getBindings(CallArranger.java:146)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.CallArranger.arrangeDowncall(CallArranger.java:153)
>     at 
> java.base/jdk.internal.foreign.abi.aarch64.macos.MacOsAArch64Linker.arrangeDowncall(MacOsAArch64Linker.java:56)
>     at 
> java.base/jdk.internal.foreign.abi.AbstractLinker.lambda$downcallHandle$0(AbstractLinker.java:52)
>     at 
> java.base/jdk.internal.foreign.abi.SoftReferenceCache$Node.get(SoftReferenceCache.java:52)
>     at 
> java.base/jdk.internal.foreign.abi.SoftReferenceCache.get(SoftReferenceCache.java:38)
>     at 
> java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:50)
>     at java.base/java.lang.foreign.Linker.downcallHandle(Linker.java:221)
>     at 
> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.RuntimeHelper.lambda$downcallHandle$5(RuntimeHelper.java:60)
>     at java.base/java.util.Optional.map(Optional.java:260)
>     at 
> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.RuntimeHelper.downcallHandle(RuntimeHelper.java:60)
>     at 
> org.librawfx at 1.8.1-SNAPSHOT/org.libraw.linuxosx.constants$3.<clinit>(constants$3.java:52)
>
>
> The code is on Github under https://github.com/lanthale/librawfx. The 
> JDK19 stuff is checked into the master branch. Just clone it and run 
> it via maven.
>
> The same I have done for LibheifFX and all is working. There must be 
> some difference how Libraw is handling all the stuff. Therefore I 
> would appreciate if you can help me.
>
> best regards,
> Clemens
>
>