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

Doug Simon dnsimon at openjdk.org
Fri May 16 06:55:52 UTC 2025


On Thu, 15 May 2025 22:24:19 GMT, Vladimir Kozlov <kvn 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 1808:
> 
>> 1806:     // is no other representation of the jdk.internal.vm.ci module
>> 1807:     // so it needs to be added to the root module set.
>> 1808:     if (ClassLoader::is_module_observable("jdk.internal.vm.ci") && !UseJVMCINativeLibrary && !_jvmci_module_added) {
> 
> In which case `ClassLoader::is_module_observable("jdk.internal.vm.ci")` == `true` when `_jvmci_module_added` == `false`?
> I assume this code is executed after check command line for `--add-modules=jdk.internal.vm.ci`.

The documentation for `is_module_observable` is:

  // Determines if the named module is present in the
  // modules jimage file or in the exploded modules directory.

That is, is the module present on disk. On the other hand, `_jvmci_module_added` is a test of whether an `--add-modules` option has been seen whose value included `jdk.internal.vm.ci`.

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

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


More information about the graal-dev mailing list