[foreign-abi] On invokers

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Sep 25 10:13:26 UTC 2019


On 25/09/2019 09:24, Nick Gasson wrote:
> Hi Jorn,
>
>>
>> If you want to do a SysV port that would be much appreciated :). In
>> principle everything in the `programmable` package, except for
>> CallArranger is a part of the API, though there should be no need to
>> interact directly with BindingInterpreter and BufferLayout. So, if you
>> want to do a port the only thing you should have to do is add a SysV
>> version of CallArranger, (which I based on CallingSequenceBuilderImpl,
>> so that's probably a good place to start) and then call that from
>> SysVx64ABI.
>>
>
> I can look at the AArch64 part, but I'm on vacation for the next two 
> weeks so it won't be anytime soon unfortunately. I like how this patch 
> removes a lot of duplication from the different architecture backends 
> in the hotspot C++ code.
>
> A slightly unrelated question, is there any way we can support some 
> kind of "fallback" invoker for hotspot ports that either don't have a 
> universal/direct invoker backed yet (e.g. 32bit Arm) or can't have one 
> (Zero)? I was thinking about something that would delegate to libffi, 
> but I'm not sure how practical that would be.

When prototyping different approaches I've used libffi many times to 
implement SystemABI, so... it can be done. That said, I'd be wary of 
creating "yet another invoker". As for ports that can't have an invoker 
implemented (Zero) because lack of support for assembly, I think nothing 
prevents these efforts from using a radically different SystemABI 
implementation which, instead of being based on assembly tricks can be 
based, as you say, on some 3rd party library (as they probably already 
do for JNI).

Maurizio

>
> Thanks,
> Nick


More information about the panama-dev mailing list