-
Enhancement
-
Resolution: Unresolved
-
P4
-
26
Currently the JVMCI version check depends on the contents of the `java.vm.version` system property. However the check is complicated, error prone and depends on non-specified details of the `java.vm.version` system property. E.g. GraalVM's LabsJDK encodes the `jvmci` string and build number into `java.vm.version` (e.g. `25+37-jvmci-b02`) but this is not the case for default OpenJDK builds.
Furthermore, the JVMCI version check in `JVMCIVersionCheck` (https://github.com/oracle/graal/blob/7a66c26d6e6/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/hotspot/JVMCIVersionCheck.java) has some extra handling of special strings like `SNAPSHOT` or `internal` in `java.vm.version` which can completely disable the check.
In the end, the [`java.vm.version` property](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#getProperties()) is really just the "*JVM implementation version in [Runtime.Version](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Runtime.Version.html#verStr) format*" which is not necessarily connected to the JVMCI version implemented by the JVM. This semantic overloading already led to problems for downstream distributions of GraalVM 25 which are not based on LabsJDK as can be seen e.g. in issue [#12188](https://github.com/oracle/graal/issues/12188).
I think it would be better to maintain a specific JVMCI version (e.g. in HotSpot's `jvmci.hpp` file) similar to the JNI, JVMTI and JMM version numbers and export that through a new and explicit system property like e.g. `jvmci.version` if JVMCI is enabled (i.e. `-XX:+EnableJVMCI`). This could be done e.g. in `JVMCI::initialize_globals()` which is called pretty early in the JVM initialization phase from `init_globals2()`.
This issue is for tracking the corresponding Hotspot part of the changes. Once the proposed Hotspot changes are in place, we can then update GraalVM's `JVMCIVersionCheck` class to first consult the corresponding explicit `jvmci.version` property if that is available. I've opened [GraalVM issue #12230](https://github.com/oracle/graal/issues/12230) to track the GraalVM part of the changes.
Furthermore, the JVMCI version check in `JVMCIVersionCheck` (https://github.com/oracle/graal/blob/7a66c26d6e6/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/hotspot/JVMCIVersionCheck.java) has some extra handling of special strings like `SNAPSHOT` or `internal` in `java.vm.version` which can completely disable the check.
In the end, the [`java.vm.version` property](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#getProperties()) is really just the "*JVM implementation version in [Runtime.Version](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Runtime.Version.html#verStr) format*" which is not necessarily connected to the JVMCI version implemented by the JVM. This semantic overloading already led to problems for downstream distributions of GraalVM 25 which are not based on LabsJDK as can be seen e.g. in issue [#12188](https://github.com/oracle/graal/issues/12188).
I think it would be better to maintain a specific JVMCI version (e.g. in HotSpot's `jvmci.hpp` file) similar to the JNI, JVMTI and JMM version numbers and export that through a new and explicit system property like e.g. `jvmci.version` if JVMCI is enabled (i.e. `-XX:+EnableJVMCI`). This could be done e.g. in `JVMCI::initialize_globals()` which is called pretty early in the JVM initialization phase from `init_globals2()`.
This issue is for tracking the corresponding Hotspot part of the changes. Once the proposed Hotspot changes are in place, we can then update GraalVM's `JVMCIVersionCheck` class to first consult the corresponding explicit `jvmci.version` property if that is available. I've opened [GraalVM issue #12230](https://github.com/oracle/graal/issues/12230) to track the GraalVM part of the changes.