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

[Alan Bateman]

On Wed, 14 May 2025 22:00:30 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, it must now be explicitly added with `--add-modules=jdk.internal.vm.ci`, which will also set `EnableJVMCI` as a side-effect.
> 
> The primary motivation is to make use of libgraal compatible with `-XX:+AOTClassLinking`. This flag 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](https://bugs.openjdk.org/browse/JDK-8342279) 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.

src/hotspot/share/runtime/arguments.cpp line 1811:

> 1809:       jio_fprintf(defaultStream::error_stream(),
> 1810:         "'+EnableJVMCI' requires '--add-modules=jdk.internal.vm.ci' when UseJVMCINativeLibrary is false\n");
> 1811:       return false;

There's something a bit uncomfortable about an error message naming a JDK internal module to specify to --add-modules.

If I understand correctly, +EnableJVMCI and libgraal is all good, the set of modules in the training run is the same as the production run. However, in the no libgraal scenario, and a mismatch between training and production runs (is that right)? then AOT is disabled. Is it really terrible to disable the AOTClassLinking optimizations in that scenario?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25240#discussion_r2092577889