March 2023 - jextract-dev

RFR: 7903239: ofAddress factory of function pointer type is wrong for struct returns
by Marko 02 Jan '24

02 Jan '24

When generating the lambda inside the `ofAddress` factory, it is missing the `SegmentAllocator` needed when the function returns a struct. This is [implemented for regular functions](https://github.com/openjdk/jextract/blob/0582eaf1b4cdba95f0ee8c2…, but not for function pointers. ------------- Commit messages: - 7903239: ofAddress factory of function pointer type is wrong for struct returns Changes: https://git.openjdk.org/jextract/pull/58/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=58&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903239 Stats: 47 lines in 3 files changed: 44 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/58.diff Fetch: git fetch https://git.openjdk.org/jextract pull/58/head:pull/58 PR: https://git.openjdk.org/jextract/pull/58

3 11

RFR: Add path independence
by Per Minborg 02 Jan '24

02 Jan '24

This small PR incorporated feedback from the original PR: https://github.com/openjdk/jextract/pull/66 made after it was integrated. ------------- Commit messages: - Add path independence Changes: https://git.openjdk.org/jextract/pull/68/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=68&range=00 Stats: 10 lines in 4 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/68.diff Fetch: git fetch https://git.openjdk.org/jextract pull/68/head:pull/68 PR: https://git.openjdk.org/jextract/pull/68

5 7

RFR: Add Dockerfile, zero-dep reproducible builds
by Gavin Ray 02 Jan '24

02 Jan '24

As title says, adds a Dockerfile that will fetch all necessary deps and build `jextract` for you on Ubuntu 22.10 It would be nice if some official JDK organization could put this on their Dockerhub, so that users could just do: $ docker run --rm -it openjdk/jextract:latest I've pushed it to my personal Dockerhub, so if anyone would like to test it out, you can use the README directions but prepend `gavinray/` before the image name: $ echo "struct Foo { int a; long b; }; int use_foo(struct Foo foo);" >> sample.h $ docker run --rm -it -v ${PWD}:/tmp/jextract \ gavinray/jextract:latest \ -I /tmp/jextract \ --source \ -l libfoo \ --output /tmp/jextract/generated \ --target-package com.example \ ------------- Commit messages: - Add Dockerfile, zero-dep reproducible builds Changes: https://git.openjdk.org/jextract/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=74&range=00 Stats: 75 lines in 2 files changed: 75 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jextract/pull/74.diff Fetch: git fetch https://git.openjdk.org/jextract pull/74/head:pull/74 PR: https://git.openjdk.org/jextract/pull/74

3 6

RFR: Add third-party sample list to README, populate with java-vulkan.
by Michael Ennen 02 Jan '24

02 Jan '24

I made a more complex example (1000 lines, mostly because setting up a boilerplate Vulkan program is super lengthy) of using jextract on Vulkan and Win32 APIs. I think it may be too lengthy and too much of a maintenance burden to commit to the `/samples` directory, so I thought maybe including a section on third-party samples would be better. If this is not something you want to entertain that's totally understandable, but thought I would put it out there a bigger sample that interfaces with a pretty complex API may be helpful to others. ------------- Commit messages: - Add third-party sample list to README, populate with java-vulkan. Changes: https://git.openjdk.org/jextract/pull/93/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=93&range=00 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/93.diff Fetch: git fetch https://git.openjdk.org/jextract pull/93/head:pull/93 PR: https://git.openjdk.org/jextract/pull/93

3 3

GPL license
by Shane Pearlman 08 May '23

08 May '23

What’s the reasoning for licensing a tool like this under the GPLv2? Code generators often need to be modified or adapted for large bindings projects, and the classes in org.openjdk.jextract.impl and org.openjdk.jextract.clang could be quite useful as a starting point. Under the current license, however, I will probably have to roll my own. Even the code generation template classes are under GPLv2, which is enough to prevent me from using jextract generated bindings in my non-GPL projects. Maybe someone’s reading of the license is that it is permissible, but is the uncertainty really necessary? That said, I am excited for the Panama project to deliver what looks to be a very well designed solution to a major, decade-long problem with Java. —Shane

3 6

RFR: 7903437: Improve translation strategy for function pointers
by Maurizio Cimadamore 23 Apr '23

23 Apr '23

The current translation stragegy for function pointers is not very efficient. Every time a lambda expression is turned into an upcall stub, a new method handle lookup is performed, which is quite a slow operation. This patch improves the translation strategy so that the lookup is only performed once. For instance, considering the following `typedef`: typedef void (*cb)(int, int); jextract will generate the following functional interface: import static java.lang.foreign.ValueLayout.*; /** * {@snippet : * void (*cb)(int,int); * } */ public interface cb { void apply(int _x0, int _x1); static MemorySegment allocate(cb fi, Arena scope) { return RuntimeHelper.upcallStub(constants$0.cb_UP$MH, fi, constants$0.cb$FUNC, scope); } static cb ofAddress(MemorySegment addr, Arena arena) { MemorySegment symbol = addr.reinterpret(arena.scope(), null); return (int __x0, int __x1) -> { try { constants$0.cb_DOWN$MH.invokeExact(symbol, __x0, __x1); } catch (Throwable ex$) { throw new AssertionError("should not reach here", ex$); } }; } } Where the constants are defined as follows: static final FunctionDescriptor cb$FUNC = FunctionDescriptor.ofVoid( Constants$root.C_INT$LAYOUT, Constants$root.C_INT$LAYOUT ); static final FunctionDescriptor cb_UP$FUNC = FunctionDescriptor.ofVoid( Constants$root.C_INT$LAYOUT, Constants$root.C_INT$LAYOUT ); static final MethodHandle cb_UP$MH = RuntimeHelper.upcallHandle(cb.class, "apply", constants$0.cb_UP$FUNC); static final FunctionDescriptor cb_DOWN$FUNC = FunctionDescriptor.ofVoid( Constants$root.C_INT$LAYOUT, Constants$root.C_INT$LAYOUT ); static final MethodHandle cb_DOWN$MH = RuntimeHelper.downcallHandle( constants$0.cb_DOWN$FUNC ); And, where `RuntimeHelper::upcallHandler` is defined as follows: static MethodHandle upcallHandle(Class<?> fi, String name, FunctionDescriptor fdesc) { try { return MH_LOOKUP.findVirtual(fi, name, fdesc.toMethodType()); } catch (Throwable ex) { throw new AssertionError(ex); } } This allows to perform the method handle lookup only once. This means that when creating an upcall stub, we only have to `bind` the functional interface instance to the method handle, and then create an upcall stub with the resulting handle. Both operations should be fast after the first time, because of caching. ------------- Commit messages: - Remove redundant import - Initial push Changes: https://git.openjdk.org/jextract/pull/109/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=109&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903437 Stats: 41 lines in 4 files changed: 28 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jextract/pull/109.diff Fetch: git fetch https://git.openjdk.org/jextract pull/109/head:pull/109 PR: https://git.openjdk.org/jextract/pull/109

4 7

Wen will jextract release new version for JDK20?
by Anivie 31 Mar '23

31 Mar '23

JDK20 has been released, it brings a lot of new features for panama projects, now the binding generated by jextract is full of errors, when will you release the jextract prepared for JDK20?

2 1

RFR: 7903449: Jextract generates structs that cannot be compiled
by Maurizio Cimadamore 30 Mar '23

30 Mar '23

While most of the constants required by jextract are stored in the auxiliary constant$xyz files, some constants are stored inside the class declaration corresponding to a struct. This was done to minimize the number of constant classes being generated. However, this can backfire, as when the generated struct is big, too many constants are added to it, which can result in a source code which fails to compile (as it's too big). Instead of doing something even more convoluted, I've decided to centralize the generation of _all_ constants under the constant$xyz files. This means that there should be no constants generated in structs (or any other "public" declaration). Doing this was problematic, as the current arrangement somehow limits the name clashes when adding constants with same name to different structs. After some attempts, I realized that the best way forward would be to simplify the `ConstantBuilder` class, so that it no longer cares about "public" Java names. Instead that class should only be used to generate declaration for constants that are used internally, by the jextract bindings. Because of that, _any_ name will do - for this reason this patch switches to a regular naming schemes for all constants, like `const$0`, `const$1`, etc. Note that these are **not** the names exposed by jextract bindings - such names (the names of the constant *getters*) are still the same as before. The main changes are around `ConstantBuilder`, which is now gone. In its place we find `Constants`, which acts as a sort of source-based constant pool. `Constants` has a cache (where already defined constants of certain kinds are stored), and new constant declarations are only emitted when needed. I've also simplified the API which is used by clients to generate constants, to remove the need of lambda expressions (which seemed a bit over the top). I've also centralize the generation of numeric constants under `Constants` as well (before, these constants where generated on the fly in `HeaderFileBuilder`). And, I also realized that our setup for sharing primitive layout constants was too complex. Most primitive layout constants are just wired to some constant in `ValueLayout`. The only special case is `C_POINTER`, which needs its *target layout* set (and presumably we only want to do that once). A much simpler solution is to just store `C_POINTER` inside `RuntimeHelper` and just use that. ------------- Commit messages: - Further simplify code - Initial push Changes: https://git.openjdk.org/jextract/pull/117/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=117&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903449 Stats: 1295 lines in 10 files changed: 525 ins; 646 del; 124 mod Patch: https://git.openjdk.org/jextract/pull/117.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/117/head:pull/117 PR: https://git.openjdk.org/jextract/pull/117

2 9

How can I generate a binding for winuser.h?
by Anivie 29 Mar '23

29 Mar '23

I am trying to generate a java binding with winuser.h, I am use this command:jextract -t com.unix C:\SDK\Mingw64\x86_64-w64-mingw32\include\winuser.h -I C:\SDK\Mingw64\x86_64-w64-mingw32\include And then, I got this error:stdlib.h:388:47: error: expected ';' after top level declarator Is there any mistake in my command? How can I fix it?

2 1

How can I generate a binding for winuser.h
by Anivie 29 Mar '23

29 Mar '23

I am trying to generate a java binding with winuser.h, I am use this command:jextract -t com.unix C:\SDK\Mingw64\x86_64-w64-mingw32\include\winuser.h -I C:\SDK\Mingw64\x86_64-w64-mingw32\include And then, I got this error:stdlib.h:388:47: error: expected ';' after top level declarator Is there any mistake in my command? How can I fix it?

1 0