Making FMA more flexible

[Maurizio Cimadamore]

On 29/04/2020 17:01, Ty Young wrote:
>
> 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?

The function descriptor has to be passed to SystemABI to create the 
handle in the first place. At this (low) level, just primitive types, 
segments and addresses.

*after* you get the method handle, you can adapt and obtain a new 
(higher-level) handle.

Maurizio

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