CLinker migration from jdk17 to jdk18

[Maurizio Cimadamore]

On 05/04/2022 15:54, Lev Serebryakov wrote:
>  So, no platform independence in client code anymore? 
I think what you call "platform independence" is largely an illusion :-)

Even in Java 17, you could have a downcall method handle that could work 
on some platforms but not on others. E.g. think about a downcall method 
handle constructed using the layout JAVA_LONG. Depending on the type 
specified in the MethodType (int.class vs. long.class) this method 
handle will not initialize depending on the platform (e.g. Linux vs. 
Windows x64).

Outside of foreign calls, it gets even worse: let's say that you have a 
struct with a couple of JAVA_LONG fields in it. What var handle should 
you use to dereference the fields? A var handle with the long.class 
carrier, or one with the int.class carrier? Again the answer is, it depends.

In other words, the situation is not different from what you get with 
JNI: when you declare a native method, e.g. to wrap a function like 
`strlen`, you have to decide if the _Java_ return type must be `int` or 
`long`. What Java type you choose determines how things are passed 
through to JNI. Of course your JNI can do clever tricks so that you can 
use `long` and make it work even when the result is really just `int`. 
But you can do similar tricks with the foreign linker API, by _adapting_ 
the dowcall method handle, and inserting the appropriate 
widening/narrowing conversions.

But, no matter what JNI tricks you might do, there is no way to e.g. 
turn an `int[]` into a `long[]`, as the two arrays just have 
incompatible layouts, so there's no easy way to paper over that 
distinction, even in JNI.

Long story short: code using the foreign linker API is as "portable" as 
code using JNI is. Additional layers of portability can be built on top 
(and we could have a discussion as to whether jextract should do 
something in this direction) - but baking them into the core API is the 
wrong move, as such layers (esp. in the array case before) come with a 
significant performance price.

Maurizio