[foreign] RFR: add support for callbacks in struct fields/globals

[Sundararajan Athijegannathan]

Looks good.

PS. I built & tested on Mac. All fine.

-Sundar

On 04/07/18, 6:24 PM, Maurizio Cimadamore wrote:
> Here's a new version of the patch:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/callback_in_structs_v2/
>
> There are many changes here:
>
> * added jextract support - jextract needs to add the new Callback 
> supertype to functional interfaces
>
> * fixed all tests to use the new Callback supertype
>
> * I did some changes so that the code uses uniformly tests like 
> Util::isCallback, Util::isCStruct; so that we can centralize the 
> checks and make sure they are applied consistently
>
> * I also did some tweaks so that CallbackImplGenerator now checks 
> whether the pointer is a native address or a binder-generated stub 
> address; in the former we just to a native call (through 
> NativeInvoker), as before - in the latter case, we dispatch doing a 
> direct Java call on the receiver we recover from the stub. So we can 
> eliminate the odd java -> native -> java sequence, for callbacks that 
> we know are binder-generated.
>
> * I've also added a test to check that functions in global variables 
> can be set and get (thanks Sundar for pointing that out!)
>
> Cheers
> Maurizio
>
>
> On 03/07/18 14:58, Maurizio Cimadamore wrote:
>> Hi,
>> this patch adds binder support for function pointers in struct 
>> fields/global variables.
>>
>> This adds a new kind of reference abstraction which handles 
>> marshalling/unmarshalling of function pointers.
>>
>> When a function pointer is retrieved from a  struct/global var, we 
>> need to create a synthetic implementation for a target functional 
>> interface whose method implementation will do a native call to some 
>> native function. Note: in some cases, the native function being 
>> called could be a binder-generated native stub - we could detect this 
>> and save the object creation and the indirect allocation, but I have 
>> not done this as part of this patch.
>>
>> When a function pointer is set, we need to obtain an address from a 
>> functional interface instance; now, if such instance is 
>> binder-generated, we have a way to retrieve such address (by calling 
>> Callback::resource). Otherwise, the instance truly comes from Java 
>> code, so we need to allocate a stub and set its address onto the 
>> struct field.
>>
>> I had to do some reshuffling of the code generation logic - there's 
>> now a new code generator (namely CallbackImplGenerator) which uses 
>> some of the features also used by HeaderImplGenerator, so I moved 
>> these shared stuff in the common superclass BinderImplGenerator.
>>
>> Also, I've tweaked NativeInvoker NOT to eagerly bind the underlying 
>> handle to a function address. That's because when we work with header 
>> symbols, we always know the address statically, and we can bind to 
>> it; but when we work with callbacks, the address is stored in the 
>> callback implementation, so it's a dynamic property. As a result, 
>> it's better not to bind the address parameter of the method handle, 
>> and have the caller pass it explicitly - which works well in both 
>> cases (and saves one bound MH creation).
>>
>> I've also added some methods to BoundedPointer in order to create an 
>> unbounded pointer with given scope: we want the pointer set on the 
>> callback implementation to have the same scope/lifecycle as the 
>> struct field it corresponds to - this allows us to throw an exception 
>> when we attempt to call a callback implementation coming from a 
>> struct field whose scope has expired.
>>
>> The added test checks some of the assertions mentioned above.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/panama/callback_in_structs/
>>
>>
>> Maurizio
>>
>>
>>
>