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

[Maurizio Cimadamore]

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/
[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/57ce26cc/attachment.htm>