Function pointers and GraalVM

[Manuel Bleichenbacher]

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/8e259c3d/attachment-0001.htm>