CLinker migration from jdk17 to jdk18

[Maurizio Cimadamore]

On 05/04/2022 18:22, Lev Serebryakov wrote:
> 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...

What you describe above is what I'm referring to - e.g. some conditional 
logic which differentiates your JNI impl based on some condition 
(sizeof(T)).

It is very possible to insert return/argument filters on a method handle 
only conditionally, which will give you more or less the same result as 
what you have in JNI.

```
MethodHandle strlen = ... // this will return `int` on LLP64 and `long` 
on LP64
if (IS_X86) {
    strlen = MethodHandles.filterReturnValue(...) // cast return to `long`
}
// now strlen always return `long`
```

Maurizio

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