Function pointers and GraalVM
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Sep 10 12:24:56 UTC 2025
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/fd1b6be0/attachment.htm>
More information about the jextract-dev
mailing list