Making FMA more flexible

[Ty Young]

On 4/29/20 6:41 AM, Maurizio Cimadamore wrote:
>
> 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


So what do you do about FunctionDescriptor? If its and the 
MethodHandle's types mismatch then an exception is thrown. Do you modify 
those after you've gotten the MemoryAddress of the MethodHandle?


> . 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
>