[foreign-memaccess+abi] RFR: 8262118: Specialize upcalls [v2]

[Jorn Vernee]

On Tue, 23 Feb 2021 11:04:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tab to spaces
>>  - Added TestMatrix test that test all configurations of TestUpcall TestDowncall and TestUpcallHightArity
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 274:
> 
>> 272:                             bindings.dup();
>> 273:                         }
>> 274:                         boolean useFloat = storage.type() == StorageClasses.VECTOR;
> 
> So , my understanding here is that we had issues all along - e.g. this is unrelated to the upcall work?

Not in issue so far since we were using an intermediate buffer. We simply write the bits as an integer, but the native code reads it as a long.

Since the specialized version doesn't use an intermediate buffer though, the types have to be aligned properly.

> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java line 134:
> 
>> 132:             MethodHandle doBindingsErased = doBindings.asSpreader(Object[].class, doBindings.type().parameterCount());
>> 133:             MethodHandle invokeMoves = insertArguments(MH_invokeMoves, 1, doBindingsErased, argMoves, retMoves, abi, layout);
>> 134:             InterpretedHandler handler = new InterpretedHandler(invokeMoves);
> 
> In principle, this could be just replaced by the method handle no? Then we could have a static entry point in this class which can be used by the VM to "call" the method handle with given args. E.g. do we need the `InterpreterHandler` wrapper?

Probably not; we could replace it with just the method handle, and then have some static entry point. I think I had more fields in there before, so it's a leftover.

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

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