Proposal: Remove EnableJVMCI flag

Mon Feb 3 19:14:08 UTC 2025

On 2/3/25 11:09 AM, Douglas Simon wrote:
> 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 agree with option 2. This looks like most reasonable approach.

Thanks,
Vladimir K

> 
>> 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
>>
> 