JDK-8314247 : JVMCI: expected int64_t but JavaThread::_held_monitor_count is of type intx
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • Submitted: 2023-08-15
  • Updated: 2023-08-15
Description
Found this exception while running graal with latest JDK mainline repo

jdk.vm.ci.common.JVMCIError: expected type int64_t but VM field JavaThread::_held_monitor_count is of type intx
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfigAccess.getField(HotSpotVMConfigAccess.java:319)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfigAccess.getFieldOffset0(HotSpotVMConfigAccess.java:165)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotVMConfigAccess.getFieldOffset(HotSpotVMConfigAccess.java:147)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.GraalHotSpotVMConfigAccess.getFieldOffset(GraalHotSpotVMConfigAccess.java:329)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.GraalHotSpotVMConfig.<init>(GraalHotSpotVMConfig.java:757)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.HotSpotGraalRuntime.<init>(HotSpotGraalRuntime.java:131)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:212)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:190)
	at jdk.internal.vm.compiler@21-internal/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:53)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:806)

Latest graal source code still has this:

https://github.com/oracle/graal/blob/d7158db906123c63ce970e535b6b3ee57574210b/compiler/src/jdk.internal.vm.compiler/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#L772-L774

        if (JDK >= 20) {
            offset = getFieldOffset("JavaThread::_held_monitor_count", Integer.class, "int64_t");
            isWord = true;
        }

But recently HotSpot refactoring in JDK-8313882 has changed this field to "intx"
Comments
It seems like the SA, JVMCI creates dependencies on the hotspot C++ code, that we tend to overlook during PR reviews. This is unfortunate.
15-08-2023
Maybe JVMCI should be more lenient when comparing types: diff --git a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java index 9954c700ca7..fec88c4001b 100644 --- a/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java +++ b/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java @@ -315,12 +315,19 @@ public class HotSpotVMConfigAccess { } // Make sure the native type is still the type we expect. - if (cppType != null && !cppType.equals(entry.type)) { + if (cppType != null && !typeEquals(cppType, entry.type)) { throw new JVMCIError("expected type " + cppType + " but VM field " + name + " is of type " + entry.type); } return entry; } + private boolean typeEquals(String t1, String t2) { + if (t1.equals("int64_t") && t2.equals("intx")) { + return true; + } + return t1.equals(t2); + }
15-08-2023