RFR: 8345826: Do not automatically resolve jdk.internal.vm.ci when libgraal is used
Doug Simon
dnsimon at openjdk.org
Thu May 15 21:54:18 UTC 2025
On Thu, 15 May 2025 16:10:12 GMT, Tom Rodriguez <never at openjdk.org> wrote:
> I found your explanation quite confusing, but the bug title is actually the most clear description of the fix. Basically libjvmci doesn't require the existence of jdk.internal.vm.ci on the HotSpot side since it has effectively compiled that into itself. So we are decoupling the ability to use JVMCI from the presence of the JVMCI module. A short comment along these lines in at least your changes in check_vm_args_consistency would be helpful I think.
I added the requested comment and tried to clarify the PR description. Let me know if clarification is needed.
> I do find it confusing that we are explicitly passing `--add-modules=jdk.internal.vm.ci` in a bunch of the tests. Is that now necessary or are you just exercising the alternate ways of enabling JVMCI?
Without that option, the module will be missing and without the fail-fast check in `check_vm_args_consistency` you would get an error such as:
Uncaught exception at src/hotspot/share/jvmci/jvmciRuntime.cpp:1433
java.lang.NoClassDefFoundError: jdk/vm/ci/code/Architecture
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (jvmciRuntime.cpp:1636), pid=1979, tid=9731
# fatal error: Fatal JVMCI exception (see JVMCI Events for stack trace): Uncaught exception at src/hotspot/share/jvmci/jvmciRuntime.cpp:1433
#
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25240#issuecomment-2885119528
More information about the graal-dev
mailing list