<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;">
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>Hi,</div>
<div><br>
</div>
<div><a href="https://bugs.openjdk.org/browse/JDK-8345826">https://bugs.openjdk.org/browse/JDK-8345826</a> was filed to make libgraal and new CDS optimizations more compatible:</div>
<div><br>
</div>
<div></div>
<blockquote type="cite">
<div>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.</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
<div>Further internal <a href="https://bugs.openjdk.org/browse/JDK-8345826?focusedId=14736369&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14736369">discussion</a> 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).</div>
<div><br>
</div>
<div>However, further reflection suggests something more aggressive is worth considering: remove the EnableJVMCI flag altogether.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>1. JVMCI as JIT.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>2. JVMCI as guest code compiler</div>
<div><br>
</div>
<div>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 <a href="https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java">module
descriptor</a>) 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
#### VM code<br>
<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 (<a href="https://github.com/openjdk/jdk/pull/23408/files#diff-ee8337800ed1d1b84e3e49a2481809a6affac5d70ca23934a44497c9c758092fR456">example</a>).</div>
<div>3. Replace EnableJVMCI with a test of whether the jdk.internal.vm.ci module has been resolved (<a href="https://github.com/openjdk/jdk/pull/23408/files#diff-4e6668d768f7d67417cbac39bcb723552cc0b80ad218709cfa0e6e31f32b69f0R518">example</a>).</div>
<div><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.</div>
<div><br>
</div>
<div>-Doug</div>
<div><br>
</div>
</div>
</body>
</html>