Unreasonable size of jextract tool
maurizio.cimadamore at oracle.com
Mon May 24 16:49:38 UTC 2021
This is a very interesting question, and one that we often stopped to
What you say is true - the static footprint of libclang is pretty high,
and we have made several experiments to try and reduce that, but w/o
much success (as the small libclang.so needs to depend on the bigger
LLVM backend). Static footprint is not the only think we're concerned
about: I think that the jextract tool isn't necessarily subject to the
same degree of compatibility requirements which apply to the various
tools shipped with the JDK. For instance, it would be ok (and I say,
even desirable) to have the shape of the generated bindings change
frequently, as new Java features become available. For instance, if
Valhalla becomes available we'd probably want to use it to model carrier
types in the generated bindings. Or, if some form of "lazy statics"
becomes available, we might be able to reduce the footprint of the
generated code (by dropping the various Constant$XYZ classes that are
What you suggest (standalone) tool is very much on the table - in fact
you will notice that we have been trying pretty hard to avoid any
dependencies on the JDK internals from jextract. That is, the
jdk.incubator.jextract package is completely standalone.
For the purpose of the EA binaries, I think having jextract in the same
place makes sense, so that people can get a feel of the API and the
toolchain. But, strictly speaking, there's nothing keeping jextract
_inside_ the JDK.
I'd be curious to hear feedback from folks who have been using jextract
- would it make a significant difference to you if jextract was
delivered in some other way? The closest thing I can think of is JMH,
which is available in the code tools repository  but also distributed
on Maven. Would a model like that be acceptable? One important use case
is the gradle jextract plugin , so I'd be curious to understand if
there would be significant repercussion on tooling build on top of
jextract, were jextract to be delivered outside the JDK.
 - https://openjdk.java.net/projects/code-tools/
 - https://plugins.gradle.org/plugin/io.github.krakowski.jextract
On 24/05/2021 17:26, Glavo wrote:
> I noticed that the jextract tool uses libclang to parse C code. On windows,
> the libclang.dll size is 67.8m, even the compressed size is about 25m. This
> makes the size of openjdk compressed package expand by 27.78%, the
> decompressed volume of openjdk expand by 34%.
> For a tool that is not commonly used, I think this is very unreasonable.
> Should we consider reducing its size in some way or distributing it as a
> stand-alone tool rather than as part of the JDK?
More information about the panama-dev