Provide a libgraal / libjvmcicompiler artifact

[bric3]

Feature request

As far as I know there's no official libgraal / libjvmcicompiler artifact, one needs to build its own, or extract it from a graalvm distribution.

Is your feature request related to a problem? Please describe.
It's more of a deployment, accountability problem.

Describe the solution you'd like.
Currently one can build libgraal, by following the instruction here:
https://github.com/oracle/graal/tree/master/compiler#libgraal. Or download a GraalVM disttribution, and extract the libgraal library.

However there's some drawbacks, the build approach as more prone to error ie build from the wrong version (not a tagged release). The download approach requires to download the whole distribution (a bit less than 500MiB) just to extract a 40 MiB lib.

I think deploying libgraal as a standalone artifact on the https://github.com/graalvm/graalvm-ce-builds/releases is likely better and could allow more people to try graal on a "regular" JVM.

On the same topic it's quite easy to get the jargraal via maven central, and add it on the command line. So it would be nice to be on par with libgraal.

Describe who do you think will benefit the most.
JDK users that would like to use Graal as a compiler.

Describe alternatives you've considered.
Manually building : libgraal

---

Thanks for all the work you put in GraalVM as a whole.

[oubidar-Abderrahim]

Thank you for your suggestion, we will take a look into it and get back to you

[oubidar-Abderrahim]

Tracked internally on GR--38550

[bric3]

Hey just for reference, upon a twitter conversation with @ionutbalosin, he shared two links related to this topic.

• https://openjdk.java.net/jeps/8223220
• And the related jira ticket to the draft JEP https://bugs.openjdk.java.net/browse/JDK-8223220

[gilles-duboscq]

In general, we don't really support this case (running libgraal or jargraal on a standard OpenJDK or OracleJDK build).
The only thing we test is the integration in GraalVM where the base Open or OracleJDK is a fork (sometimes called "labsjdk", see labs-openjdk-11 & labs-openjdk-17).
We try to upstream all the relevant changes but there can be a bit of latency and some of the changes might not always be backported to the relevant version (currently 11 & 17) once they reach upstream (currently 19).

In general, i would recommend using GraalVM CE or EE if you want to use the Graal compiler.

Maybe you could describe your use-case where you instead need to run on standard Open/OracleJDK?

[bric3]

Hi @gilles-duboscq, there is several reasons.

• Reducing the image container size, A GraalVM distribution can be around 1GiB unpacked, while an OpenJDK distribution is around 300MiB
• Some JDK have specific features
  e.g.
  • JetBrains runtime has specific Swing fixes and is shipped JCEF
  • Corretto, usually can be shipped with specific fixes, that usually gets back-ported upstream.
  • OpenJDK have other GCs, Shenandoah and ZGC in particular. I know these are not yet supported currently, due to some barrier implementation not implemented in Graal. If this ever happen 🙂, (Support for ZGC (garbage collector) #2149 Support for Shenandoah GC #3472 Implement Shenandoah barriers #2426 👀).
• The organization policy may have restriction the JDK distribution

We try to upstream all the relevant changes but there can be a bit of latency and some of the changes might not always be backported to the relevant version (currently 11 & 17) once they reach upstream (currently 19).

But this affects the Graal jars as well, right ?

[gilles-duboscq]

Regarding size, there are reduced distributions available (such as modular RPMs) but we'd need to work on making those more accessible

We try to upstream all the relevant changes but there can be a bit of latency and some of the changes might not always be backported to the relevant version (currently 11 & 17) once they reach upstream (currently 19).

But this affects the Graal jars as well, right ?

I'm not sure I understand the question.

What I meant is that a given OpenJDK distribution might not contain some of the patches that are in the labsjdk used to build GraalVM. In the case the patches do make it upstream into the corresponding jdkXXu repository, it might be after a given GraalVM release.

[bric3]

In the case the patches do make it upstream into the corresponding jdkXXu repository, it might be after a given GraalVM release.

It might a bit tedious to track for a distinct native libgraal artefact. Of course if those patches are not back-ported then for sure it prevents the usage of the graal compiler.

We try to upstream all the relevant changes but there can be a bit of latency and some of the changes might not always be backported to the relevant version (currently 11 & 17) once they reach upstream (currently 19).

But this affects the Graal jars as well, right ?

I'm not sure I understand the question.

Since Graal is written in Java, I understood that patches that are not yet upstream will/may affect the graal compiler jar (and other deps) which is available on maven central.
Ie when a OpenJDK is run with -XX:+EnableJVMCI --module-path=... --upgrade-module-path=... there could be issues as well.

Or is there some specifics with the native libgraal that happen to go beyond the JVM Compiler Interface ?

[gilles-duboscq]

Since Graal is written in Java, I understood that patches that are not yet upstream will/may affect the graal compiler jar (and other deps) which is available on maven central.
Ie when a OpenJDK is run with -XX:+EnableJVMCI --module-path=... --upgrade-module-path=... there could be issues as well.

That's right. it's not a tested / supported configuration either

[gilles-duboscq]

We have no plans to distribute libgraal separately