[GR-70043] Improve and simplify JVMCI version checking

[simonis]

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 is really just the "JVM implementation version in Runtime.Version 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.

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().

I've created JDK-8368582: [JVMCI] Improve and simplify JVMCI version checking 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.

[dougxc]

Before answering the specific proposal, let me clarify the situation for Graal development moving forward. As of #12210, Graal is now developed on JDK 25 and is no longer tracking OpenJDK master (currently JDK 26). There are 2 streams of Graal based on JDK 25:

• Release: This is the version of Graal released on Sept 21 (https://docs.oracle.com/en/graalvm/jdk/25/index.html). This stable/maintenance stream will only receive critical patches and security fixes going forward. The repo+branches involved are:
  • https://github.com/oracle/graal/tree/release/graal-vm/25.0
  • https://github.com/graalvm/labs-openjdk/tree/release/jvmci/25.0
• Feature: This is the focus for active development from which a future release will be made at some non-yet-determined date. The repo+branches involved are:
  • https://github.com/oracle/graal/tree/master
  • https://github.com/graalvm/labs-openjdk/tree/jdk25

Given that the Release stream aims to be stable, it makes sense to apply your proposal to it. That is, JVMCI can be backwards compatible within this stream.

For the Feature stream, we need more flexibility, especially in the context of Project Terminus which aims to detach Graal from HotSpot (and thus HotSpot JVMCI) altogether. Once Terminus is done, there will most likely only be an SVM and Espresso implementation of JVMCI and this JVMCI will live entirely in the Graal repo. In that setup, there's obviously no need for a version check.

With that context, I'm happy to sponsor and review PRs that implement your proposal on the Release stream.