[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