RFR: 8345826: Do not automatically resolve jdk.internal.vm.ci when libgraal is used [v3]

[Doug Simon]

On Fri, 16 May 2025 14:41:31 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The `EnableJVMCI` flag currently serves 2 purposes:
>> * Guards VM code ([example](https://github.com/openjdk/jdk/blob/b1e778d9d2ad13ee5f1ed629a8805008580f86c0/src/hotspot/share/runtime/sharedRuntime.cpp#L652)).
>> * [Adds](https://github.com/openjdk/jdk/blob/b1e778d9d2ad13ee5f1ed629a8805008580f86c0/src/hotspot/share/runtime/arguments.cpp#L1804) `jdk.internal.vm.ci` to the root module set.
>> 
>> This PR changes nothing about the first point.
>> 
>> On the second point, to use the `jdk.internal.vm.ci` module when libgraal is enabled, `--add-modules=jdk.internal.vm.ci` must be specified.
>> If libgraal is not enabled, +EnableJVMCI will continue to add `jdk.internal.vm.ci` to the root module set.
>> 
>> The primary motivation is to make use of libgraal compatible with `-XX:+AOTClassLinking`. This flag relies on the root module set archive created in a training run. If the root module set is different in the production run, the AOTClassLinking [optimizations](https://bugs.openjdk.org/browse/JDK-8342279) are disabled. As `jdk.internal.vm.ci` is not resolved in the training run, it must not be resolved in production run. As such, `-XX:+EnableJVMCI` must not cause resolution of `jdk.internal.vm.ci`, otherwise libgraal will not have the startup advantages of AOTClassLinking.
>
> Doug Simon has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fixed comment
>  - removed use of jdk.internal.vm.ci.enabled property
>  - fix TestHotSpotJVMCIRuntime

While testing this out on Graal, I discovered an interesting corner case.


public class UseJVMCIModule {
    public static void main(String[] args) {
        jdk.vm.ci.runtime.JVMCI.getRuntime();
    }
}


If the JVMCI module is indirectly added to the root module set, it results in an error:

java --add-modules=jdk.graal.compiler --add-exports=jdk.internal.vm.ci/jdk.vm.ci.runtime=ALL-UNNAMED UseJVMCIModule.java
Exception in thread "main" java.lang.InternalError: JVMCI is not enabled
	at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method)
	at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:64)
	at UseJVMCIModule.main(UseJVMCIModule.java:3)


That is, if an app wants to use the JVMCI module, it needs to explicitly communicate this to the launcher. By the time the root module graph is being initialized in ModuleBootstrap, it's too late to set `EnableJVMCI`.

I improved the error message to make this clear:

Exception in thread "main" java.lang.InternalError: JVMCI is not enabled. Must specify '--add-modules=jdk.internal.vm.ci' or '-XX:+EnableJVMCI' to the java launcher.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25240#issuecomment-2887219662