RFC: Refactoring SystemABI

[Maurizio Cimadamore]

Btw - many thanks for pushing this forward! I think this will really be 
a crucial move in (a) allowing a more casual way to bind native methods 
(which is what Jorn is rightly asking for) and (b) decoupling the binder 
from the implementation enough so that other platform ABIs can be 
slotted in with less risk of interacting with existing code.

So - keep going!

Thanks
Maurizio

On 16/11/2018 18:25, Henry Jen wrote:
> Thanks, this is the kind of response I wanted to see, as I mentioned this is just first step, so that we can get a taste. The points you mentioned are all the valid and is planned for next.
>
>> On Nov 16, 2018, at 2:06 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> Hi Henry,
>> the work looks like a good initial step. But I think you didn't go all the way through with it. That is, the binder code (HeaderImplGenerator and ScopeImpl) still rely on UpcallHandler/NativeInvoker. I think it would be nice if we could completely decouple these things. After all, everything that HeaderImplGenerator needs is a way to get a method handle for a given downcall, and that can be done directly through SystemABI, now.
>>
>> For upcalls its a bit harder, given that for an upcall there's currently some info associated to it:
>>
>> * receiver object
>>
>> * address of the generated stub
>>
>> * target method handle
>>
>> plus a way to 'free' the stub generated by the VM.
>>
>> I think the best way to get there is to create an intermediate abstraction that holds these info (plus a free() method), call it 'UpcallHandle' (removed the final 'R') and then let the binder program against this. Then, a Callback object is essentially an UpcallHandle + a Java carrier (functional interface) + a scope.
>>
> Yes, I think the SystemABI should return UpcallHandle instead of Pointer, and let scope to wrap that up in a Pointer and handle the free. Current API makes that hard and we see the ugly business to retrieve the UpcallHandler from the address in binder.
>
>> But UpcallHandler as it is now, is not a mere abstraction describing an upcall - it also embodies the strategy by which the upcall is performed (e.g. direct vs. universal) in the same way a NativeInvoker does. So I think that moving forward we would probably want to just have SystemABI select the right NativeInvoker/UpcallHandler to do the job - and these things don't have to be superclasses, or induce a hierarchy of any kind - e.g. it would be ok for a DirectInvoker to be completely unrelated from a UniversalInvoker. As long as the rest of the binder only interacts with SystemABI, that's ok.
>>
> I agrees. I was thinking moving that code into ABI implementation but leave it in the static method for now, which really can be moved around, either into a helper class or in ABI itself.
>
> Cheers,
> Henry
>
>> Maurizio
>>
>>
>>
>> On 15/11/2018 22:44, Henry Jen wrote:
>>> Hi,
>>>
>>> Please have a look at the webrev[1] refactor the SystemABI APIs based on Mauricio’s proposal. SystemABI is suppose to encapsulate platform-specific details, this patch make NativeInvoker/UpcallHander and CalllingSequence to be implementation details, and thus can further be simplified/removed if we need to.
>>>
>>> The binder suppose to only interact with SystemABI, that’s not completed yet in this webrev, but follow up work should get us there.
>>>
>>> Concept of CallingConvention is introduced as an abstraction for now and is currently simply support default.
>>>
>>> Anyway, it’s just first step, and I would like to see if it make sense to us.
>>>
>>> Cheers,
>>> Henry
>>>
>>> [1] http://cr.openjdk.java.net/~henryjen/panama/SystemABI/webrev/