jextract woes

[Michael Zucchi]

On 29/1/20 11:23 am, Maurizio Cimadamore wrote:
>
> On 29/01/2020 00:06, Michael Zucchi wrote:
>>
>> I'm not sure how that can be done by extending the jextract generated 
>> class though (i mean it's final anyway right ;-)? Unless you mean by 
>> just calling the RuntimeHelper methods manually which sort of defeats 
>> the purpose.
> I think that, for this kind of stuff you are in jextract API 
> territory. We could provide the plumbing for creating such 
> 'dynamically-addressed' MHs, but you will have to create them by hand 
> (or prorammatically, if you have a well-known way to list the 
> extensions).

Ok, I will have to wait and see what you come up with before 
proceeding.  And for the latter i usually just use a text file - no tool 
can guess what's important.

>>
>> 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
         )
     );
    }