[foreign-jextract] Generated getters and setters do not include offsets

[Maurizio Cimadamore]

On 31/08/2020 12:50, Filip Krakowski wrote:
> Hi,
>
> omitting the "--source" flags yields class files producing the 
> expected result. Does this mean source code generation takes another 
> path than bytecode generation? I thought that omitting the "--source" 
> flag would just compile the generated sources for convenience. I also 
> inspected the bytecode using javap and saw that the PathElements are 
> there.

There's currently a bug in source generation (which was only added 
recently); we will take care of that. The path is slightly different in 
that there are two backend implementation for generating constants - one 
that is classfile based (written on top of ASM) and one that is more 
string-y, which enables source generation.

For maximum performances, using the classfile based generation is gonna 
yields better results, since we can take advantage of lazy features that 
are only available at the classfile level (the ldc + dynamic constants). 
For source-based artifacts there's no alternative to having a big static 
initializer which installs all the native method handle in one shot - if 
startup is a concern, classfile generation might be better here.

Maurizio

>
> Best regards,
> Filip
>
> On 31.08.20 13:25, Maurizio Cimadamore wrote:
>> Hi
>> this seems an issue with source code generation - can you please 
>> verify that w/o the --source flag the behavior is as expected?
>>
>> (seems like source generation is omitting layout paths when 
>> generating VH accessors)
>>
>> Maurizio
>>
>> On 31/08/2020 11:35, Filip Krakowski wrote:
>>> Hi,
>>>
>>> I just noticed that jextract's generated getters and setters always 
>>> access the provided MemorySegment at offset 0. This looks like a bug 
>>> to me.
>>>
>>> This is the struct I used to reproduce this issue.
>>>
>>>    struct coordinate {
>>>       int x;
>>>       int y;
>>>    };
>>>
>>>
>>> And this is the code jextract generated from it (source mode).
>>>
>>>    private static final MemoryLayout coordinate$struct$LAYOUT_ 
>>> =MemoryLayout.ofStruct(
>>>         C_INT.withName("x"),
>>>         C_INT.withName("y")
>>>    ).withName("coordinate");
>>>
>>>    public static jdk.incubator.foreign.MemoryLayout
>>>    coordinate$struct$LAYOUT() {return coordinate$struct$LAYOUT_; }
>>>
>>>    private static final MemoryLayout coordinate$x$LAYOUT_ =C_INT;
>>>    public static jdk.incubator.foreign.MemoryLayout 
>>> coordinate$x$LAYOUT() {return coordinate$x$LAYOUT_; }
>>>
>>>    private static final VarHandle coordinate$x$VH_ 
>>> =coordinate$x$LAYOUT_.varHandle(int.class);
>>>    public static java.lang.invoke.VarHandle coordinate$x$VH() 
>>> {return coordinate$x$VH_; }
>>>
>>>    private static final MemoryLayout coordinate$y$LAYOUT_ =C_INT;
>>>    public static jdk.incubator.foreign.MemoryLayout 
>>> coordinate$y$LAYOUT() {return coordinate$y$LAYOUT_; }
>>>
>>>    private static final VarHandle coordinate$y$VH_ 
>>> =coordinate$y$LAYOUT_.varHandle(int.class);
>>>    public static java.lang.invoke.VarHandle coordinate$y$VH() 
>>> {return coordinate$y$VH_; }
>>>
>>>
>>> Here I allocate the struct, set both fields and print them afterwards.
>>>
>>>    try (var segment =coordinate.allocate()) {
>>>         coordinate.x$set(segment,1);
>>>         coordinate.y$set(segment,2);
>>>
>>>         System.out.println(coordinate.x$get(segment));
>>>         System.out.println(coordinate.y$get(segment));
>>>    }
>>>
>>>
>>> This will print "2" twice, although "x" should be set to "1" in my 
>>> understanding.
>>>
>>> I am using the latest build (commit 
>>> 4d7888c040767760b6250130ef6024ea16b43461).
>>>
>>>
>>> Best regards,
>>> Filip
>