Error during opening a native lib on Apple M1

[Clemens Lanthaler]

Hi Maurizio,

I have tried to filter as much as possible but it seems that this is the 
basic functionality of the libraw lib. Therefore it seems that I have to 
exclude the lib on Apple devices until it is solved out - Means waiting 
for another JDK version.

On Windows at least all is working as expected.

best regards,
Clemens


On 05.09.22 10:40, Maurizio Cimadamore wrote:
> 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
>>
>>

-- 
ITArchitects
CEO: B.Sc. Clemens Lanthaler
Forchachstrasse 3
A-6166 Fulpmes
Tel.: +43 (0)650 855 2954
email: office at itarchitects.at
homepage: http://www.itarchitects.at
-------------------------------------------------
Notice: This e-mail and any attachments are confidential and may be privileged.
If you are not the intended recipient, notify the sender immediately, destroy all
copies from your system and do not disclose or use the information for any purpose.
Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem
Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie
bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und
veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x94A919BE276C7EA1.asc
Type: application/pgp-keys
Size: 2476 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220905/651445e7/OpenPGP_0x94A919BE276C7EA1-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220905/651445e7/OpenPGP_signature-0001.sig>