Function pointers and GraalVM

[Manuel Bleichenbacher]

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. 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).
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).

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/465106db/attachment-0001.htm>