CLinker migration from jdk17 to jdk18

[Lev Serebryakov]

On 05.04.2022 20:06, Maurizio Cimadamore wrote:

> 
> 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.
  In JNI I could have #ifdef's which are somewhat platform-independent: check not platform names and compilers, but "sizeof(type)". For example I could always use 64 bit jlongs on JNI boundaries, and cast them from/to 32 bit longs on LLP64 platform, I don't need to know is it Windows or some other LLP64 platform.  And it will be as effective as possible.

  As far as I can see (correct me if I'm wrong) Foreign API now operates not in terms of LP64/LLP64 but Windowsx64 / SysVx64, etc. Looks like here are not abstract platform capabilities, but list of supported platforms.

  Also, as far as I understand (again. correct me if I'm wrong), it is impossible to have MethodHandle which will do such casting behind the scene if (and only if) it is needed...

  Problems with native structs and arrays which contain longs (as most problematic type) are understood, of course.


-- 
// Black Lion AKA Lev Serebryakov