Proposal: Remove EnableJVMCI flag

[Vladimir Kozlov]

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.

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

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

Thanks,
Vladimir K

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
>