Proposal: Remove EnableJVMCI flag

[Douglas Simon]

Hi Vladimir,

On 3 Feb 2025, at 18:45, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

Hi Doug,

My concern is that some code (stubs, blobs, Interpreter) are generated before we are loading any modules.
How you handle JVMCI specific code there if you have it? If you don't have such code than we can discuss.

You mean what would we do with generated code that currently tests EnableJVMCI? We have these 2 options as far as I can see:
1. Always generate the JVMCI part of the code (example<https://github.com/openjdk/jdk/pull/23408/files#diff-524c9e019cb83916aa3db772fb33acbbe3e7465867a8d2f7e6376be3c8260eddL606>).
2. Instead of testing EnableJVMCI, we instead test a JVMCI::_is_enabled bool which would be initialized during argument parsing (i.e. before any code is generated). JVMCI::_is_enabled would be set to true if jdk.internal.vm.ci is in the root module set or if any other JVMCI flags such as UseGraalJIT or UseJVMCICompiler are true. I suspect this option is the one to go with as it’s pretty much equivalent to the current semantics (i.e. JVMCI conditional VM is only executed/generated) if JVMCI is enabled.

I definitely against adding runtime checks for JVMCI presence into executed (assembler) code.

I agree that we do not want that.

Would be nice if/when command line is parsed we can detect presence of `--add-modules=jdk.internal.vm.ci` (or others related) flag and enable JVMCI flag. I am fine to keep `EnableJVMCI` but make it ergonomic.

I’d like EnableJVMCI to become purely an alias for --add-modules=jdk.internal.vm.ci.

You may still want to disable JVMCI from command line even if somewhere in start script you have `--add-modules=jdk.internal.vm.ci`.

I don't think we need to support such a contradiction - if the launcher has been asked to load jdk.internal.vm.ci as part of the root module set, then it wants JVMCI enabled. Either that or we make -EnableJVMCI undo any preceding --add-modules=jdk.internal.vm.ci (if that’s even possible).

-Doug

On 2/1/25 12:03 AM, Douglas Simon wrote:
Hi,
https://bugs.openjdk.org/browse/JDK-8345826 <https://bugs.openjdk.org/browse/JDK-8345826> was filed to make libgraal and new CDS optimizations more compatible:
Since JDK 483, many more CDS optimizations are enabled when -XX:+AOTClassLinking is specified (see numbers in https:// bugs.openjdk.org/browse/JDK-8342279). However, these optimizations require the archived module graph to be used. Today, if you enable UseGraalJIT, the archived module graph will be disabled. As a result, the *entire* CDS archive will be disabled. This will result in slower start-up time when UseGraalJIT is enabled.

Further internal discussion <https://bugs.openjdk.org/browse/JDK-8345826? focusedId=14736369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14736369> resulted in the proposal to remove all use of EnableJVMCI in the VM code. This will mean -XX:+EnableJVMCI only applies to the Java code (i.e. adds jdk.internal.vm.ci to the root module set).
However, further reflection suggests something more aggressive is worth considering: remove the EnableJVMCI flag altogether.
This option was implemented to make use of JVMCI opt-in. However, JVMCI is effectively opt-in anyway without this option. There are two ways in which JVMCI can be used: as a JIT compiler by the CompileBroker and as a compiler for “guest” code (e.g., Truffle use case).
1. JVMCI as JIT.
To enable JVMCI as JIT, flags such as UseJVMCICompiler, UseGraalJIT or EnableJVMCIProduct must be specified to the java launcher. Each of these flags set EnableJVMCI to true as a side-effect. That is, use of JVMCI as JIT is already opt-in due to needing these other flags - specifying EnableJVMCI is redundant.
2. JVMCI as guest code compiler
In this mode, the jdk.internal.vm.ci module must be loaded (i.e. EnableJVMCI currently has the side-effect of `--add- modules=jdk.internal.vm.ci`). This module has no unqualified exports (as seen in its module descriptor <https:// github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java>) so using it requires specifying at least one instance of --add-exports to the Java launcher. That is, once again EnableJVMCI alone is not sufficient for opting-in to JVMCI.
In light of the above, I propose removing EnableJVMCI altogether. This will require using --add- modules=jdk.internal.vm.ci when you actually want to use the JVMCI module. It will also require modifying JDK code guarded by this flag. It guards both VM code and use of the `jdk.internal.vm.ci` module and I consider them separately below.
#### VM code
All uses of EnableJVMCI to guard VM code would adapted with one of the following strategies:
1. Remove the guard and make the code unconditional.
2. Replace EnableJVMCI with something else such as UseJVMCICompiler or test of a global variable set to true as soon as JVMCI compiled code is about to be installed in the code cache (example <https://github.com/openjdk/jdk/pull/23408/ files#diff-ee8337800ed1d1b84e3e49a2481809a6affac5d70ca23934a44497c9c758092fR456>).
3. Replace EnableJVMCI with a test of whether the jdk.internal.vm.ci module has been resolved (example <https:// github.com/openjdk/jdk/pull/23408/files#diff-4e6668d768f7d67417cbac39bcb723552cc0b80ad218709cfa0e6e31f32b69f0R518>).
Of course, this change almost certainly needs a CSR as well but I’d like to get feedback on the primary change before worrying about that.
-Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250203/40ea2a36/attachment.htm>