[foreign-memaccess+abi] RFR: 8255903: Enable multi-register return values for native invokers [v3]

[Jorn Vernee]

On Thu, 28 Oct 2021 14:14:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> In theory merging the two would be possible, but it would significantly blur the line between which parts of the binding recipe are handled by Java code, and which parts are handled by the VM code: currently the VM only handles the move bindings, but it would have to be re-written to handle buffer stores in certain cases as well. As you say, the problem is that the VM doesn't know at which offsets the return values should be stored.
>> 
>> I thought of other solutions here as well, like using a Java object instead of an off-heap buffer to hold the intermediate values which would make the allocation cheaper, or to wait for Valhalla, which would give us Java types that take up multiple registers when returning as well, in which case those could be used as a carrier type instead of having an intermediate return buffer. (the latter seems like the most attractive option to me).
>> 
>> So, I punted on this problem for now. My main objective of adding support for multi-register returns with this patch is to be able to remove the buffered invocation strategy.
>
> I was thinking the same, and I thought that using an intermediate object (not a segment) would probably be a good idea. E.g.
> 
> class ReturnBuffer {
>    long first;
>    long second;
> }
> 
> For now this is just a plain identity class. When we have Valhalla, we can make this a value. But I think even now it should work more efficiently than allocating a segment with malloc (as I hope this object will be scalarized).

We can't get object scalarization unfortunately, because the object escapes into an out-of-line call (to the native invoker).

Generating classes like this also fits nicely into another issue I wanted to tackle at some point: adding some kind of tuple class generation factory to java.lang.invoke. (related to https://bugs.openjdk.java.net/browse/JDK-8182862)

Any ways, benchmarking + implementing this seemed like enough effort for a separate patch, so I went with the simplest implementation in this PR.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/603