CLinker migration from jdk17 to jdk18

[Remi Forax]

----- Original Message -----
> From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> To: "Lev Serebryakov" <lev at serebryakov.spb.ru>, "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Sent: Tuesday, April 5, 2022 7:30:49 PM
> Subject: Re: CLinker migration from jdk17 to jdk18

> 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`
> ```

or MethodHandle.asType() for cast from int to long (cast without loss of precision) and MethodHandles.explicitCastArguments() for cast from long to int (cast with loss of precision).

> 
> Maurizio
> 

Rémi