RFC: Refactoring SystemABI

[Jorn Vernee]

Maybe this concern is being raised prematurely. I think we can see how 
the current plans pans out and then look at this again if needed.

Jorn

Jorn Vernee schreef op 2018-12-04 16:34:
> Maurizio Cimadamore schreef op 2018-12-04 16:07:
>> On 04/12/2018 14:23, Jorn Vernee wrote:
>>> We have Scope::allocateCallback to replace step 2. and 3., but that 
>>> requires an annotated functional interface object. What if a user 
>>> just has a MethodHandle?
>> 
>> Not sure I follow - a Callback is based on the idea that you _do have_
>> a functional interface.
> 
> The scenario I'm talking about still uses a functional interface
> _type_. But the Scope::allocateCallback api expects _an instance_ of
> such a functional interface type; So if you just have a MethodHandle
> you would first have to turn it into an instance of this functional
> interface type and then call Scope::allocateCallback. This adds a
> level of indirection, and AFAIK there's no straight forward API for
> wrapping a MethodHandle in a functional interface in the JDK
> (MethodHandleProxies comes close but it relies on reflection, so it's
> slow).
> 
> So what I'm talking about is that a user can use System::upcallStub to
> make the MethodHandle callable from native, but if they have some
> other method that accepts a Callback there still needs to be a way to
> convert the value returned from upcallStub into a Callback.
> 
>> I don't think it makes sense to mix the abstraction levels - the
>> binder will represent all callbacks using Callback, so I don't expect
>> a user of the high-level binder to mess with SystemABI interface to
>> allocate stubs.
> 
> I was thinking about the inverse; we have a user who is using the
> low-level SystemABI, and wants to have the high-level addition of
> Callback. This also makes sense where low-level code has to interact
> with high-level code.
> 
> Jorn