Making FMA more flexible

[Maurizio Cimadamore]

On 29/04/2020 05:00, Ty Young wrote:
> Hi all,
>
>
> I'm trying to create an abstraction over the native upcall callback 
> functionality of FMA. Problem is, FMA as it stands is too rigid. 
> FunctionDescriptor only accepts primitive types plus MemoryAddress 
> which is a problem since I don't want to have to deal with raw 
> MemoryAddress(s) at the callback's end.
>
>
> I've also noticed this issue with VarHandles in that it is not 
> possible to quickly convert a returned MemoryAddress into something 
> useful unless it's a primitive.
>
>
> I think FMA needs to be a bit more flexible in this regards. Maybe 
> somekind of custom serialization and deserialization functionality? I 
> don't know, but I do know it's at best an annoyance and at worse a 
> road blocker for abstracted callbacks.

I believe all the problems you mentioned can be worked around by using 
MethodHandle (and now VarHandle) adapters. Yes, the API will give you 
low-level VH and MH, but the sky is the limit there - you can take those 
VH and MH and insert whatever adaptation you think is important. For 
instance, you can go from a MH whose signature is this:

(MemorySegment, MemorySegment, MemoryAddress)void

to one whose signature is this

(PointStruct, TimeStruct, IntPointer)void

and this is relatively easy to do with method handle combinators:

https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/invoke/MethodHandles.html#filterArguments(java.lang.invoke.MethodHandle,int,java.lang.invoke.MethodHandle...)

One of the main addition that the FMA has as of late is that now VH can 
be adapted too - so again you can filter access coordinates, transform 
carriers and all you like.

I would expect frameworks to do this quite routinely (e.g. turn the raw 
VH/MH the API gives to them into something which speaks in terms of the 
abstraction they work with).

Maurizio