Questions about JEP442 at https://openjdk.org/jeps/442

[Cheng Jin]

Hi Maurizio,

Many thanks for the detailed clarifications.

As for this linker option for downcall,  does it mean users need to specify Linker.Option.isTrivial() at https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/java/lang/foreign/Linker.Option.html#isTrivial() to enable the optimization?

Best Regards
Cheng Jin

From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Sent: May 9, 2023 4:41 PM
To: Cheng Jin <jincheng at ca.ibm.com>; panama-dev at openjdk.org
Subject: [EXTERNAL] Re: Questions about JEP442 at https://openjdk.org/jeps/442

Hi, some comments inline below: On 09/05/2023 18: 28, Cheng Jin wrote: Hi there, I feel confused with the following descriptions in JEP442 at https: //openjdk. org/jeps/442: Provided a linker option to optimize calls to functions that are short-lived
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Hi, some comments inline below:
On 09/05/2023 18:28, Cheng Jin wrote:
Hi there,

I feel confused with the following descriptions in JEP442 at https://openjdk.org/jeps/442<https://openjdk.org/jeps/442>:
Provided a linker option to optimize calls to functions that are short-lived and will not upcall to Java (e.g., clock_gettime);

Can anybody explain what the linker option is intended for (assuming it is used in upcall?) and how it works in terms of the optimization in there?
This option only affects calls from Java to native. When you go from Java to native there is some bookkeeping required in order to change the thread state from Java-state to native-state (and back when you leave). While these transitions are quick (typically < 5ns), there are some edge cases where clients working in low-latency environments really need to shave off every last nanosecond out of a native call - especially native calls such as e.g. gettime which can return very quickly. Of course, removing thread transitions comes with big caveats too: a native function called in this way would have to terminate quickly (as GC would be disabled for the duration of the call), and it can never upcall back to Java. As such, this is a mechanism that should only really be used in very specific cases, by a very specific set of developers. (You might have heard of the term "critical JNI" [1] in the past - this option in some way is a replacement for that functionality).



Another question is about the fallback linker: Provided a fallback native linker implementation, based on libffi

It seems to me t that it is never used unless the current platform has no support on the foreign linker as indicated in code at java.base/share/classes/jdk/internal/foreign/CABI.java:

       if (ForeignLinkerSupport.isSupported()) {
       ...
       } else if (FallbackLinker.isSupported()) {
            return FALLBACK; // fallback linker
       }

If so, what is the background of introducing this kind of linker? and where can it be used?

This linker can be used on all platforms which do not provide any low level support for the linker API. For instance in the case of the zero assempler port [1] which, by definition, doesn't provide any way to generate assembly on the fly. This has more to do with allowing the linker API to be supported in extreme situations, but not something the user really has to care about. The big benefit, however, is that the user can expect the Linker API to be supported in more platforms [3].

I hope this helps.

Maurizio

[1] - https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/<https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/>
[2] - https://openjdk.org/projects/zero/<https://openjdk.org/projects/zero/>
[3] - https://mail.openjdk.org/pipermail/porters-dev/2023-March/000753.html<https://mail.openjdk.org/pipermail/porters-dev/2023-March/000753.html>



Best Regards
Cheng Jin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230509/45624fbe/attachment-0001.htm>