Unreasonable size of jextract tool

[Maurizio Cimadamore]

Hi,
This is a very interesting question, and one that we often stopped to 
ponder.

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

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 [1] but also distributed 
on Maven. Would a model like that be acceptable? One important use case 
is the gradle jextract plugin [2], 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.

Thanks
Maurizio

[1] - https://openjdk.java.net/projects/code-tools/
[2] - 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?