<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Vladimir,<br id="lineBreakAtBeginningOfMessage">
<br>
<blockquote type="cite">On 3 Feb 2025, at 18:45, Vladimir Kozlov <vladimir.kozlov@oracle.com> wrote:<br>
<br class="Apple-interchange-newline">
Hi Doug,<br>
<br>
My concern is that some code (stubs, blobs, Interpreter) are generated before we are loading any modules.<br>
How you handle JVMCI specific code there if you have it? If you don't have such code than we can discuss.<br>
</blockquote>
<div><br>
</div>
<div>You mean what would we do with generated code that currently tests EnableJVMCI? We have these 2 options as far as I can see:</div>
<div>1. Always generate the JVMCI part of the code (<a href="https://github.com/openjdk/jdk/pull/23408/files#diff-524c9e019cb83916aa3db772fb33acbbe3e7465867a8d2f7e6376be3c8260eddL606">example</a>).</div>
<div>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.</div>
<div><br>
</div>
<blockquote type="cite">I definitely against adding runtime checks for JVMCI presence into executed (assembler) code.<br>
</blockquote>
<div><br>
</div>
I agree that we do not want that.
<div><br>
<blockquote type="cite">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.</blockquote>
<div><br>
</div>
<div>I’d like EnableJVMCI to become purely an alias for --add-modules=jdk.internal.vm.ci.</div>
<br>
<blockquote type="cite">You may still want to disable JVMCI from command line even if somewhere in start script you have `--add-modules=jdk.internal.vm.ci`.<br>
</blockquote>
<div><br>
</div>
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).</div>
<div><br>
</div>
<div>-Doug</div>
<div><br>
</div>
<div>
<blockquote type="cite">On 2/1/25 12:03 AM, Douglas Simon wrote:<br>
<blockquote type="cite">Hi,<br>
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:<br>
<blockquote type="cite">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.<br>
<br>
</blockquote>
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).<br>
However, further reflection suggests something more aggressive is worth considering: remove the EnableJVMCI flag altogether.<br>
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).<br>
1. JVMCI as JIT.<br>
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.<br>
2. JVMCI as guest code compiler<br>
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.<br>
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.<br>
#### VM code<br>
All uses of EnableJVMCI to guard VM code would adapted with one of the following strategies:<br>
1. Remove the guard and make the code unconditional.<br>
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>).<br>
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>).<br>
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.<br>
-Doug<br>
</blockquote>
<br>
</blockquote>
<br>
</div>
</body>
</html>