[foreign] RFR: do not infer layout from Java signatures

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Fri May 18 12:57:14 UTC 2018


In test/jdk/java/nicl/System/UnixSystem.java test :)

-Sundar

On 18/05/18, 6:25 PM, Sundararajan Athijegannathan wrote:
> +1.
>
> Except that you need to fix Mac specific layout
>
>     @NativeHeader
>     static interface MacOSXSystem {
>         @C(file="dummy", line=1, column=1, USR="c:@F at stat")
>         
> @NativeType(layout="(p:cp:[iSSQIIi[ll][ll][ll][ll]qqiIIi2q])i", 
> ctype="dummy", size=1)
>         @CallingConvention(value=1)
>         public abstract int stat$INODE64(Pointer<Byte> path, 
> Pointer<stat> buf);
>
> -Sundar
>
> On 18/05/18, 5:00 PM, Maurizio Cimadamore wrote:
>> Hi,
>> as part of the cleanup I pushed yesterday, I realized there are quite 
>> few places where the binder infers layouts from the Java signatures 
>> rather than sticking to what the annotations say. This patch fixes 
>> such bad usages.
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/dont-infer-layout-v2/src/java.base/share/classes/jdk/internal/nicl/Util.java.udiff.html 
>>
>>
>> The only place where we need to do something like this is with 
>> variadic calls; so Util still has a function that goes from Class to 
>> Layout, but its scope is much more limited, and the resulting layout 
>> is also approximate (I've added comments in that direction), since 
>> varargs are always passed in register-aligned slots, regardless of 
>> the underlying real layout - so we don't need much 'inference' there.
>>
>> I fixed a test which was missing layout annotation in a Java callback.
>>
>> Maurizio
>>
>>


More information about the panama-dev mailing list