jextract woes

[Jorn Vernee]

On 29/01/2020 04:24, Michael Zucchi wrote:
> On 29/1/20 11:23 am, Maurizio Cimadamore wrote:
>>
>> On 29/01/2020 00:06, Michael Zucchi wrote:
>>>
>>> If i follow your second paragraph correctly regarding alternative 
>>> boostrapping, how does application state get into there, potentially 
>>> multiple times?
>>
>> bootstrapping is done only the first time a given method handle is 
>> called - that is, the bootstrapping logic is the very logic that 
>> gives you the method handle. This can do something simple, or 
>> something fairly complex (e.g. obtain an address entry point from 
>> another native call and then construct the handle from it). But once 
>> the bootstrap returns the handle, the assumption is that the handle 
>> will be reused (and the VM can assume it is a 'constant'). In other 
>> words, the VM sees that it needs to either resolve a 'dynamic 
>> constant' (condy) or invoke a 'dynamic method' (indy) and in the 
>> process of resolving such dynamic entities it will end up calling 
>> user-defined bootstrapping logic (written in Java).
>>
>> You can get quite wild with the kind of stuff you can do at this 
>> level (and implementors of dynamic languages on top of the JVM indeed 
>> have :-) ) - but a lot of this stuff is, at least currently, not 
>> expressible in terms of Java source code.
>
> I see where that works for a single resolution function which can use 
> global context (e.g. glXGetProcAddress), but what about one that can 
> return multiple values for multiple contexts?  Don't you just have to 
> create a new method handle every time anyway (once per function, per 
> context)?
>
> i.e. how do i solve the problem i've described in a way that isn't 
> just the same as simply doing this (assuming such a variation of 
> downcallHandle()  call existed):
>
>     public static final MethodHandle clEnqueueTask(MemoryAddress addr) {
>       return RuntimeHelper.downcallHandle(
>         addr, "clEnqueueTask",
> "(Ljdk/incubator/foreign/MemoryAddress;Ljdk/incubator/foreign/MemoryAddress;ILjdk/incubator/foreign/MemoryAddress;Ljdk/incubator/foreign/MemoryAddress;)I", 
>
>         FunctionDescriptor.of(MemoryLayouts.SysV.C_INT, false,
>             MemoryLayouts.SysV.C_POINTER,
>             MemoryLayouts.SysV.C_POINTER,
>             MemoryLayouts.SysV.C_INT,
>             MemoryLayouts.SysV.C_POINTER,
>             MemoryLayouts.SysV.C_POINTER
>         )
>     );
>    }

The assumption is that a function call at a particular call site would 
at least have the same type and name between invocations (otherwise they 
would be pretty hard to use). If the target function for a particular 
call site can change during the lifetime of the application; use an 
interface with multiple implementations, one for each target.

Jorn