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

[Maurizio Cimadamore]

On 09/05/2023 22:07, Cheng Jin wrote:
>
> 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?
>
Yes, you need to pass this "trivial" linker option when creating a 
downcall method handle (note that the downcall method handle factory 
method accepts a varargs of linker options).

Maurizio

> 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:
>
>     */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://urldefense.com/v3/__https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/__;!!ACWV5N9M2RV99hQ!KzszxNKci3FnbYarVj8AXwe_Mzua_DqjXqby51t6ctmIMyqLC9Xas2myACu7hYxx3-BRAWS0lHfs7RgJepChNxGD$>
> [2] - https://openjdk.org/projects/zero/
> [3] - 
> 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/bb775a99/attachment.htm>