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

[Maurizio Cimadamore]

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
>
>
>