[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