search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.36k stars 1.63k forks source link

Provide a libgraal / libjvmcicompiler artifact #4511

Closed bric3 closed 11 months ago

bric3 commented 2 years ago

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 commented 2 years ago

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

oubidar-Abderrahim commented 2 years ago

Tracked internally on GR--38550

bric3 commented 2 years ago

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

gilles-duboscq commented 2 years ago

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 commented 2 years ago

Hi @gilles-duboscq, there is several reasons.

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 11 months ago

We have no plans to distribute libgraal separately