RFC: Refactoring SystemABI

[Maurizio Cimadamore]

On 23/11/2018 12:04, Jorn Vernee wrote:
> Hi,
>
> I was mostly trying to paint a complete picture of what happens with 
> upcalls, together with some ideas of my own, to get the discussion 
> started. I was trying to get the story straight on the differences 
> between UpcallHandle and UpcallHandle**r**. The version of 
> UpcallHandle I suggested was made on the assumption that that's the 
> main minimal interface, and the getReceiver was a special case for 
> optimization (that we could maybe get rid of).
>
> I really like your idea. I think it also allows us to get rid of the 
> receiver parameter, and instead ask for a bound method handle when 
> creating an upcall stub;
>
>     default Pointer<?> upcallStub(MethodHandle target, 
> NativeMethodType nmt)
>
> From what I can tell, the receiver is only being saved separately in 
> order to return it later when asked for it. But now that SystemABI 
> only has to return a MethodHandle, we only need to save a MethodHandle.

I was about to write an email on that topic and got distracted - stay 
tuned for more

Maurizio

>
> Your idea should also simplify a lot of the Callback/callback 
> generation code, since there will be only 1 code path to take.
>
> Btw, I looked at integrating this patch in my local copy, but there 
> were a lot of conflicts in the invokers package, so I will wait until 
> these are moved over to the ABI impl package, and I should have an 
> easier time doing that.
>
> Cheers,
> Jorn
>
> Maurizio Cimadamore schreef op 2018-11-23 03:06:
>> On 23/11/2018 01:47, Maurizio Cimadamore wrote:
>>> What is it that bothers you about this approach?
>>
>> Let me clarify - I like that you are thinking of ways to reduce the
>> surface of the API - but it seems that moving a method (getReceiver)
>> from UpcallHandle to SystemABI doesn't buy all that much.
>>
>> I personally prefer having a simple UpcallHandle lookup method in the
>> ABI, and then a way to get form the Handle to the receiver as it seems
>> more composable this way. Right now, true, we always need to do both
>> things at the same time (to speed up things in the upcall machinery),
>> but maybe having a 'are you a stub' predicate will turn out handy even
>> on its own (in case the user wants to write some pointer-walking
>> code).
>>
>> But, if we really wanted to save some API estate, I think a better
>> approach (if viable) would be to completely hide the stub detection
>> logic. As you said very clearly yourself, we have this issue:
>>
>> "There is a shortcut being taken when native code gives us a Pointer
>> back to one of our upcall stubs, and we want to call it from Java. In
>> that case we don't really need to call into native, to call our own
>> upcall stub to then call back into Java to call our target method."
>>
>> This is the reason behind the 'isStub/getReceiver' logic. But let's
>> analyze this use case more in detail: we have a pointer to function,
>> and we want to do a downcall using that pointer as the entry point.
>> But this means that, in order to do the downcall, we will call
>> SystemABI.downcallHandle (again). So, I think it is theoretically
>> possible that the ABI would say: "hey, I know this guy!" and instead
>> of giving you a MethodHandle that 'goes down' it gives you a
>> MethodHandle that stays in Java-land. And the binder would not even
>> know.
>>
>> If my conjecture is correct, then we just need your minimal
>> UpcallHandle interface (pointer + free) and no
>> getReceiver/getFunctorObject at all. And, if you pull on this some
>> more, you realize that UpcallHandle is not even needed: just use a
>> Pointer, and add a 'freeUpcallHandle(Pointer<?>)' to the SystemABI.
>> That'd be sweet.
>>
>> Thoughts?
>>
>> Maurizio