[foreign] rethinking Panama annotations

[Maurizio Cimadamore]

Good catch, I fixed the table (again :-))

Maurizio

On 26/11/2018 19:57, Jorn Vernee wrote:
> Looking at the new table, I see now that the annotation is on the 
> function descriptor and not on the address layout for the Layout-Based 
> approach as well. This seems strange to me since the layout hole 
> `@{qsortComp}` will be replaced by `u64:(i32 i32)i32`, not just by 
> `(i32 i32)i32`, so I'd expect the name annotation to be on the address 
> layout, not on the function descriptor.
>
> This is why I was confused that the declaration for the layout based 
> approach didn't parse for me; I thought the name annotation was 
> supposed to be on the layout.
>
> Jorn
>
> Maurizio Cimadamore schreef op 2018-11-26 19:45:
>> 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