Function pointers and GraalVM

[Manuel Bleichenbacher]

Hi Maurizio

Yes, your experiment code is exactly what would be needed. It has the
simple static invoker method (as proposed by the pull requests) and it does
not generate code for getter, setter and upcalls. It's probably all that is
needed for the "functional struct" use case.

Regards
Manuel


Am Mi., 10. Sept. 2025 um 17:50 Uhr schrieb Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

>
> On 10/09/2025 14:12, Manuel Bleichenbacher wrote:
>
> Hi Maurizio
>
> The pull request solves something different. It simplifies invoking
> function pointers that are part of a struct. For COM interfaces and similar
> constructs, this is quite useful.
>
> However, the code for the upcall and downcall handle hasn't changed. They
> are still static fields of an inner class. So they will always be
> instantiated as a pair.
>
> But it might be useful to go one step further with this pull request and
> not emit the upcall (method handle, function interface, "apply" method) if
> the "functional" option is specified.
>
> Apologies -- that is what I assumed the changes in the PR did. I believe
> it should be possible to at least enhance the PR that way and then try
> things out. @Nizar could you please look into this?
>
> I did something like this in our jextract/ONNX/Babylon experiment
>
>
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java
>
> (as you can see there's no upcall handles there, as they were not needed).
>
> Or even consider emitting code like my Windows API Generator does for COM
> interfaces (see
> https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md
> <https://urldefense.com/v3/__https://github.com/manuelbl/WindowsApiGenerator/blob/main/docs/com_interfaces.md__;!!ACWV5N9M2RV99hQ!IvvUYfukc401IJY8ml05l3Br5O2zP9NNaFN0JHeYgLetR8-G3vGu2SasWYB1phslKRoYTjaelHHiU5OcLIcPmfi7f8dQsqzrow$>).
> It doesn't create an interface for each function pointer, but a single one
> for the entire struct, separate implementation classes for downcalls
> (calling a COM interface) and upcalls (implementing COM interfaces).
>
> I _think_ I did something like this in our jextract/ONNX/Babylon experiment
>
>
> https://github.com/openjdk/babylon/blob/code-reflection/cr-examples/onnx/src/main/java/oracle/code/onnx/foreign/OrtApi.java
>
> (as you can see there's no interfaces and no upcall handles there, as they
> were not needed).
>
> Is that similar to what you had in mind?
>
> Maurizio
>
>
> By the way: the current pull request has a further problem. I generates
> code that doesn't compile. Depending on the arguments of the function
> pointer, the setter and the invoker method have the same arguments and
> clash.
>
> Regards
> Manuel
>
>
> Am Mi., 10. Sept. 2025 um 14:25 Uhr schrieb Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com>:
>
>> Seems related to this?
>>
>> https://git.openjdk.org/jextract/pull/287
>>
>> It would be very helpful if you could try the option in that PR (you
>> would need to build jextract manually) and see if that improves the
>> situation.
>>
>> Cheers
>> Maurizio
>> On 10/09/2025 12:46, Manuel Bleichenbacher wrote:
>>
>> Hi jextract team
>>
>> I've been playing with the upcoming GraalVM 25 and its support for FFM.
>> But I've run into an issue with code generated by jextract related to
>> function pointers: it always instantiates both the downcall and upcall
>> method handles, independent of which one is actually used. In my case, I
>> would only need the downcall handle. The unnecessary upcall handle depends
>> on another method ("apply") that GraalVM has correctly identified to never
>> be called and is thus omitted from the native image. As a result, the
>> application crashes at run-time.
>>
>> It wouldn't be such a problem if I was dealing with one or two function
>> pointers. Then I would manually create the required FFM code with downcall
>> handles only. However, I'm dealing with COM interfaces and the macOS IOKit
>> version thereof:
>>
>> *typedef* *struct* IOUSBInterfaceStruct942 {
>>
>>     IUNKNOWN_C_GUTS;
>>
>>     IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*,
>> CFRunLoopSourceRef *source);
>>
>>     CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*);
>>
>>     IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t
>> *port);
>>
>>     mach_port_t (*GetInterfaceAsyncPort)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceOpen)(*void* **self*);
>>
>>     IOReturn (*USBInterfaceClose)(*void* **self*);
>>
>>     IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass);
>>
>>     IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8
>> *intfSubClass);
>>
>>     IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8
>> *intfProtocol);
>>
>>     IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor);
>>
>>     ...
>>
>> These are structs that almost exclusively consist of function pointers.
>> In the case of IOKit, the two main ones consist of 40 and 50 function
>> pointers.
>>
>> Am I correct that there is currently no way to suppress the generation of
>> upcall method handles?
>>
>> Are there any plans to to make the jextract generated code work well with
>> GraalVM?
>>
>> Regards
>> Manuel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250910/67747139/attachment.htm>