Open sgammon opened 4 months ago
For Truffle users, this may surface as:
[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot engine uses a fallback runtime that does not support runtime compilation to native code.
Execution without runtime compilation will negatively impact the guest application performance.
The following cause was found: JVMCI is not enabled for this JVM. Enable JVMCI using -XX:+EnableJVMCI.
For more information see: https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support.
To disable this warning use the '--engine.WarnInterpreterOnly=false' option or the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
... emitted from the prepareNativeOptimizations
and prepareJitOptimizations
tasks.
cc / @melix @graemerocher
There's unfortunately no API in Gradle to figure out if we should use toolchains or not. I think we can workaround by adding one configurable to these tasks. However, your use case is interesting: how do you make a difference between GraalVM and a regular JDK? In Micronaut we've explicitly removed toolchain detection because it's impossible to make the difference so it causes a lot more pain to users than the other way around.
@melix in our case it would be best to have full control, to be able to set a javaLauncher
or javaCompiler
. We obtain these from the toolchain APIs manually and then assign them in each task, like compileJava
or nativeCompile
. As far as I can tell, the AOT tasks are using JavaExec
under the hood, but we can't address these tasks to customize them.
It would also cover all use cases of our style to provide some sort of .configure
. For example:
tasks.someAotTask {
javac.configure {
// runs in the context of a `JavaCompile` task, maybe?
javaCompiler = myCompilerFromToolchains
}
}
We are of course happy to work with whatever we can get though :)
Expected Behavior
Running
prepareNativeOptimizations
orprepareJitOptimizations
should use the same Java toolchain assigned tojavaCompile
, to avoid issues related to pinned JDKsActual Behaviour
AbstractMicronautAotCliTask
usesgetExecOperations().javaexec(...)
without awareness of toolchains; there is no way to assign thejavaLauncher
orjavaCompiler
for aAbstractMicronautAotCliTask
, and so the user has a choice: disable toolchains and rely onJAVA_HOME
, or live with the toolchain the task selects.In my case, I need GraalVM so that I can pre-optimize my app which uses Truffle. Truffle needs a GraalVM JDK, or a
javac
/java
run enabled with-XX:+EnableJVMCI
and--upgrade-module-path
. I tried this approach, but was unable to resolve the JAR needed for the GraalVM compiler since Gradle runs the AOT task configuration quite early in the build graph.Ultimately, the user should have the ability to control the toolchain for the AOT tasks.
Steps To Reproduce
See above
Environment Information
Example Application
No response
Version
4.4.0