Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building Mandrel/libgraal at tag mandrel-23.1.2.0-Final with JDK 17 doesn't work #688

Closed
simonis opened this issue Mar 1, 2024 · 5 comments
Labels
question Further information is requested wontfix This will not be worked on

Comments

@simonis
Copy link

simonis commented Mar 1, 2024

I only open this ticket to save a useful Slack conversation for better visibility and such that I can still find it in a few weeks :)

I have problems building Mandrel/libgraal at tag mandrel-23.1.2.0-Final with upstream OpenJDK 17.0.10. Building at tag mandrel-22.3.5.0-Final works fine.Here's what I'm doing (for mandrel-23.1.2.0-Final):

$ git clone https://github.com/openjdk/jdk17u-dev
$ cd jdk17u-dev
$ git checkout jdk-17.0.10-ga
$ configure ...
$ make graal-builder-image

$ export JAVA_HOME=<path-to>/jdk17u-dev-opt/images/graal-builder-jdk
$ export PATH=<path-to>/Graal/mx:$PATH

$ mkdir Mandrel && cd Mandrel
$ git clone https://github.com/graalvm/mandrel
$ cd mandrel
$ git checkout mandrel-22.3.5.0-Final
$ cd vm
$ mx --env libgraal build
...
[libjvmcicompiler:180684] Finished generating 'libjvmcicompiler' in 34.6s.

However, when switching to mandrel-23.1.2.0-Final the build fails as follows:

$ mx clean
$ git checkout mandrel-23.1.2.0-Final
$ mx --env libgraal build
...
[libjvmcicompiler:188117] GraalVM Native Image: Generating 'libjvmcicompiler' (shared library)...
[libjvmcicompiler:188117] ========================================================================================================================
[libjvmcicompiler:188117] [1/8] Initializing...Compiling jdk.internal.vm.compiler.test with javac-daemon(JDK 17)... [dependency GRAAL_PROCESSOR updated]

                                                          (0.0s @ 0.30GB)
Error: Substitution target for com.oracle.svm.core.jdk.Target_javax_crypto_JceSecurity_IdentityWrapper is invalid as inner class IdentityWrapper in javax.crypto.JceSecurity can not be found. Make sure that the inner class is present.
com.oracle.svm.core.util.UserError$UserException: Substitution target for com.oracle.svm.core.jdk.Target_javax_crypto_JceSecurity_IdentityWrapper is invalid as inner class IdentityWrapper in javax.crypto.JceSecurity can not be found. Make sure that the inner class is present.
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.abort(UserError.java:73)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.findTargetClass(AnnotationSubstitutionProcessor.java:1082)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleClass(AnnotationSubstitutionProcessor.java:373)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.init(AnnotationSubstitutionProcessor.java:351)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.createAnnotationSubstitutionProcessor(NativeImageGenerator.java:1029)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:907)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:590)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:550)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:539)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:721)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:143)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:98)

As far as I can see, this is caused by "[23.0] Mandrel 23.0 fails to build with JDK 17.0.10-EA" which was fixed by #609 in the mandrel/23.0 branch, but not in the mandrel/23.1 branch (on which the tag mandrel-23.1.2.0-Final is defined).On the other hand, building mandrel-23.1.2.0-Final works with upstream OpenJDK 21 (i.e. 21.0.0) but fails again with the latest 21.0.4 development version because of:

[libjvmcicompiler:214857] ========================================================================================================================
[libjvmcicompiler:214857] GraalVM Native Image: Generating 'libjvmcicompiler' (shared library)...
[libjvmcicompiler:214857] ========================================================================================================================
[libjvmcicompiler:214857] [1/8] Initializing...
                                                          (0.0s @ 0.19GB)
Error: could not find target field: static int com.oracle.svm.core.thread.Target_java_lang_VirtualThread.RUNNABLE
com.oracle.svm.core.util.UserError$UserException: could not find target field: static int com.oracle.svm.core.thread.Target_java_lang_VirtualThread.RUNNABLE
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.abort(UserError.java:73)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.util.UserError.guarantee(UserError.java:97)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.findOriginalField(AnnotationSubstitutionProcessor.java:913)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleFieldInAliasClass(AnnotationSubstitutionProcessor.java:550)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleAliasClass(AnnotationSubstitutionProcessor.java:428)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleClass(AnnotationSubstitutionProcessor.java:395)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.init(AnnotationSubstitutionProcessor.java:351)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.createAnnotationSubstitutionProcessor(NativeImageGenerator.java:1029)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:907)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:590)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:550)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:539)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:721)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:143)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:98)

So my questions are:

  1. Where can I find a mapping of supported combinations of Mandral branches/tags to OpenJDK versions?
  2. Will fixes from mandrel/23.0 not be forward ported to mandrel/23.1 or is this just something nobody had the time to do until now?
  3. Will mandrel/23.1 not be supported on JDK17 on principle or has just nobody had the time to fix it until now?
@simonis simonis added the bug Something isn't working label Mar 1, 2024
@simonis
Copy link
Author

simonis commented Mar 1, 2024

@jerboaa answered:

Hi Volker!

mandrel/23.1 is JDK 21 only. The last JDK 17 based version is 23.0 Also note, that we don't test libgraal at all, so it might work or might not work (at runtime/build time).

I suggest to use the latest released JDK (or the tag) for each mandrel version (or the upcoming EA version). By using the jdk17u-dev and jdk21u-dev trees you are using too new versions of the JDK. The releases give you some clues as to which JDK version was used. For the next update we have:

Mandrel 23.0.4 => JDK 17.0.11
Mandrel 23.1.3 => JDK 21.0.3

Older release links:
https://github.com/graalvm/mandrel/releases/tag/mandrel-23.1.2.0-Final (21.0.2)
https://github.com/graalvm/mandrel/releases/tag/mandrel-23.0.3.0-Final (17.0.10)

In other words building from jdk17u and jdk21u trees should work. Just don't use the -dev versions.

@simonis
Copy link
Author

simonis commented Mar 1, 2024

Hi Severin,

Thanks a lot for the quick response. https://github.com/graalvm/mandrel/releases contains exactly the version mappings I was interested in!

However, for me as a newbie in this project, it is still a little confusing which versions are supported on which JDK. E.g. you said that 23.0 is the last JDK 17 based version. What is that dependent on? Is this decision taken in the upstream project or is this a decision taken in the Mandrel fork? It also seems strange to me that a minor version change from 23.0 to 23.1 drops JDK 17 support?

Also, what's the LTS strategy for Graal/Mandrel? E.g. JDK 17 is a LTS release with support until at least 2027. Is there a Graal community version which aligns with the support time frames of the OpenJDK LTS versions?

E.g. looking at older releases at https://github.com/graalvm/mandrel/releases I can see that 21.3 supported JDK 17 and JDK 11 from 21.3.0.0-Final up to 21.3.6.0-Final. But since April 2023, there are no more 21.3 releases so users will have to migrate to 22.0 or later, right? But then again, 22.2.0.0-Final (from July 2022) seems to be the last version supported on JDK 11, although JDK 11 is still a fully supported OpenJDK LTS version.

Is there a concept of LTS versions for Graal/Mandral a community of maintainers similar to what we have in OpenJDK? (edited)

@simonis
Copy link
Author

simonis commented Mar 1, 2024

Answer from @jerboaa:

Mandrel (as a downstream distro of GraalVM), takes all this info from upstream's community edition. There is nothing similar to the long lifetime of OpenJDK (in the GraalVM community world) AFAIK. Take a look at:
https://www.graalvm.org/release-calendar/
and the Oracle GraalVM schedule here:
https://docs.oracle.com/en/graalvm/release-calendar.html
Mandrel has the update cycle aligned to the Quarkus lifecycle.

The closest concept of LTS is 23.0 for JDK 17, 23.1 for JDK 21 and likely 25.1 for JDK 25. And yes, the version numbers don't tell you all that much in the world of GraalVM in terms of major/minor (re: dropping JDK support). There was a recent shift from the old model of one GraalVM version supporting multiple JDK versions to only supporting the latest JDK. I.e. GraalVM for JDK 21 (internal version 23.1) only supporting JDK 21.

GraalVM for JDK 22 (internal version 24.0) only supporting JDK 22, etc.

@simonis
Copy link
Author

simonis commented Mar 1, 2024

Thanks a lot @jerboaa for this very useful information!

Regarding 23.1.2 on JDK 17 I did some experiments (just for the sake of getting a feeling for the differences between 22 and 23 and what it takes to keep things working on older JKDs).

  • With the attached patch it is possible to build the native libgraal compiler (i.e. libjvmcicompiler.so) with JDK 17 (that was the easy part).
  • Unfortunately that doesn't help a lot. It will indeed successfully load the native compiler when running with JDK 17, but it doesn't really work. It immediately crashes with:
    Your Java runtime '17.0.10-internal+0-adhoc.ec2user.jdk17u-dev' with compiler version '23.1.2' is incompatible with polyglot version '23.1.2'.
    The Java runtime version must be greater or equal to JDK '21' and smaller than JDK '25'.
    ...
    
  • While the first part of the message is a little bit misleading (i.e. "compiler version '23.1.2' is incompatible with polyglot version '23.1.2'") the actual reason is really the too old JDK version (i.e. "The Java runtime version must be greater or equal to JDK '21' and smaller than JDK '25'").
  • While the version check can be disabled with -Dpolyglotimpl.DisableVersionChecks=true, this only leads to a set of real issues, s tarting with:
    Caused by: java.lang.RuntimeException: java.lang.NullPointerException: cannot resolve type without an accessing class
      at java.util.Objects.requireNonNull(Objects.java:235)
      at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.lookupType(HotSpotJVMCIRuntime.java:891)
      at com.oracle.svm.graal.hotspot.libgraal.truffle.HSTruffleCompilerRuntime.resolveType(HSTruffleCompilerRuntime.java:215)
      at org.graalvm.compiler.truffle.compiler.AbstractKnownTruffleTypes.lookupTypeOptional(AbstractKnownTruffleTypes.java:69)
      at org.graalvm.compiler.truffle.compiler.KnownTruffleTypes.<init>(KnownTruffleTypes.java:70)
      at org.graalvm.compiler.truffle.compiler.hotspot.HotSpotKnownTruffleTypes.<init>(HotSpotKnownTruffleTypes.java:60)
      at org.graalvm.compiler.truffle.compiler.hotspot.HotSpotTruffleCompilerImpl.create(HotSpotTruffleCompilerImpl.java:144)
      at com.oracle.svm.graal.hotspot.libgraal.truffle.TruffleToLibGraalEntryPoints.newCompiler(TruffleToLibGraalEntryPoints.java:186)
      at com.oracle.truffle.runtime.hotspot.libgraal.TruffleToLibGraalCalls.newCompiler(Native Method)
      at com.oracle.truffle.runtime.hotspot.libgraal.LibGraalHotSpotTruffleCompiler.lambda$getOrCreateIsolate$0(LibGraalHotSpotTruffleCompiler.java:72)
      at com.oracle.truffle.runtime.hotspot.libgraal.LibGraalIsolate.getSingleton(LibGraalIsolate.java:99)
      at com.oracle.truffle.runtime.hotspot.libgraal.LibGraalHotSpotTruffleCompiler.resolveIsolateHandleImpl(LibGraalHotSpotTruffleCompiler.java:80)
      at com.oracle.truffle.runtime.hotspot.libgraal.LibGraalHotSpotTruffleCompiler.getOrCreateIsolate(LibGraalHotSpotTruffleCompiler.java:70)
      at com.oracle.truffle.runtime.hotspot.libgraal.LibGraalHotSpotTruffleCompiler.initialize(LibGraalHotSpotTruffleCompiler.java:91)
      at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntime.initializeTruffleCompiler(HotSpotTruffleRuntime.java:324)
      at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntime$1.accept(HotSpotTruffleRuntime.java:270)
      at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntime$1.accept(HotSpotTruffleRuntime.java:266)
      at com.oracle.truffle.runtime.CompilationTask.call(CompilationTask.java:232)
      at com.oracle.truffle.runtime.CompilationTask.call(CompilationTask.java:55)
      at java.util.concurrent.FutureTask.run(FutureTask.java:264)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
      at java.lang.Thread.run(Thread.java:840)
      at com.oracle.truffle.runtime.BackgroundCompileQueue$TruffleCompilerThreadFactory$1.run(BackgroundCompileQueue.java:303)
    
  • ..which is caused by massive changes in JVMCI between JDK 17 and 21 (e.g. JDK-8303646) and corresponding changes in libgraal between 22 and 23 which arn't that easy to fix (at least not for me 🙂).

Thanks one more time for your support and have a nice weekend!

@simonis
Copy link
Author

simonis commented Mar 1, 2024

Closing as won't fix.

@simonis simonis closed this as completed Mar 1, 2024
@jerboaa jerboaa added wontfix This will not be worked on question Further information is requested and removed bug Something isn't working labels Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants