RFC: Refactoring SystemABI

[Jorn Vernee]

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.

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