[foreign] rethinking Panama annotations

[Maurizio Cimadamore]

On 26/11/2018 18:42, Jorn Vernee wrote:
> This seems fine to me, after all Callbacks are a carrier for function 
> pointers, so @NativeCallback declaring the layout of a function 
> pointer seems to make sense from a user perspective as well.
>
> Just so we're clear, wouldn't the use site of Layout-Based actually be 
> `qsort=(u64: i32 i32 ${qsortComp})v` instead of `qsort=(u64: i32 i32 
> u64:${qsortComp})v` (so without the u64:)?
>
Yep - cut and paste issue, corrected here

http://cr.openjdk.java.net/~mcimadamore/panama/callback-table.html

> Also, `Layout.of("u64:(i32 i32)(qsortComp)i32")` is not parsing for 
> me, I have to use `Layout.of("u64(qsortComp):(i32 i32)i32")`, and then 
> the name correctly appears on the returned layout as well.

That depends on the patch submitted for RFR this morning, see [2]

[2] 
http://mail.openjdk.java.net/pipermail/panama-dev/2018-November/003287.html

>
> Jorn
>
> Maurizio Cimadamore schreef op 2018-11-26 18:56:
>> On 26/11/2018 14:15, Maurizio Cimadamore wrote:
>>
>>> separate patch for adding support for descriptor name resolution in
>>> callbacks
>>
>> I've been thinking more about this, and it's not as easy as it looks
>> at first...
>>
>> The issue is that if we want to support resolution for both struct
>> names and callback names, that means that Unresolved essentially
>> becomes a 'descriptor', not a layout. But if we pull on this string
>> more, then we need to replace descriptor for layout everywhere in the
>> API, de facto flattening the API (e.g. clients will be using
>> descriptor everywhere, thus making the descriptor vs. layout split
>> useless).
>>
>> The only way I see to support name resolution for callbacks and, at
>> the same time, retain the descriptor vs. layout split, is to tweak the
>> @NativeCallback annotation so that its value attribute describes a
>> full address layout, not just the signature of the callback - e.g.
>>
>>  Vanilla
>>  Descriptor-based
>>  Layout-based
>>
>>  Declaration
>>  @NativeCallback("(i32 i32)i32")
>> interface QsortComp { ... } @NativeCallback("(i32 i32)(qsortComp)i32")
>> interface QsortComp { ... } @NativeCallback("u64:(i32
>> i32)(qsortComp)i32")
>> interface QsortComp { ... }
>>
>>  Use-site
>>  qsort=(u64:[0i32]i32i32u64:(u64:i32u64:i32)i32)v
>>          qsort=(u64: i32 i32 u64:${qsortComp})v
>>          qsort=(u64: i32 i32 u64:${qsortComp})v
>>
>> So, first notice how much compaction we get by being able to refer to
>> callbacks by name - the use site values in the second and third column
>> are clearly more legible than the one in the first column, in which
>> tne entire callback signature has to be repeated (which is also error
>> prone, if you write these things by hand).
>>
>> The difference between descriptor-based and layout-based is that in
>> the former, we are able to refer to a function descriptor directly
>> using an unresolved hole; in the latter case, the unresolved hole will
>> resolve to a layout (an address layout whose pointee is a function).
>> Therefore, the layout-based approach preserves all the properties we
>> care about: it allows to retain the distinction between layouts and
>> functions, while at the same time allowing for some for of by-name
>> reference for callbacks. The small price to pay is that the contents
>> of the @NativeCallback annotation will now contain not just the
>> callback signature, but the full address layout corresponding to a
>> function pointer associated to that callback.
>>
>> Is this something that we consider acceptable?
>>
>> Cheers
>> Maurizio