RFC: Refactoring SystemABI

[Henry Jen]

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/