In JDK-8298099, we have decoupled libgraal from jdk.internal.vm.ci.

However, since JDK 23, with the Oracle JDK, you can enable libgraal with one of the following:

java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProduct ...
java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler ...

Both EnableJVMCIProduct and UseJVMCICompiler set EnableJVMCI to true:

https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L65
https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L89

This causes the following code to be executed in arguments.cpp to add the jdk.internal.vm.ci module.

  if (status && EnableJVMCI) {
    PropertyList_unique_add(&_system_properties, "jdk.internal.vm.ci.enabled", "true",
        AddProperty, UnwriteableProperty, InternalProperty);
    if (ClassLoader::is_module_observable("jdk.internal.vm.ci")) {
      if (!create_numbered_module_property("jdk.module.addmods", "jdk.internal.vm.ci", _addmods_count++)) {
        return false;
      }
    }
  }

Since libgraal doesn't require the jdk.internal.vm.ci module, it should not be resolved implicitly when -XX:+UseGraalJIT is specified.

The primary motivation is to make use of libgraal compatible with -XX:+AOTClassLinking. The latter relies on an archive of the root module set created in a separate JVM execution. If the root module set is different than what's in the archive at runtime, the AOTClassLinking optimizations are disabled. As jdk.internal.vm.ci is not resolved when creating the archive, it must not be resolved in the runtime using the archive. As such, -XX:+EnableJVMCI must not cause resolution of jdk.internal.vm.ci for libgraal to have the startup advantages of AOTClassLinking.

Basically the ability to use JVMCI should be decoupled from the resolution of the JVMCI module.