-
Bug
-
Resolution: Fixed
-
P2
-
21
As a result of the changes in jvmciCompilerToVM.cpp for JDK-8301995, building libgraal on jdk21+16 does not work:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/oops/constantPool.hpp:256), pid=30379, tid=9219
# assert(is_invokedynamic_index(i)) failed: i=8
#
Stack: [0x000000016ef70000,0x000000016f973000], sp=0x000000016f96d2e0, free space=10228k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x112dcdc] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x990 (con
stantPool.hpp:256)
V [libjvm.dylib+0x112e32c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x68
V [libjvm.dylib+0x5d6358] report_vm_error(char const*, int, char const*, char const*, ...)+0x60
V [libjvm.dylib+0x5af0] ConstantPool::decode_invokedynamic_index(int)+0x60
V [libjvm.dylib+0xc6ed58] LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x44
V [libjvm.dylib+0xc6e834] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0x134
V [libjvm.dylib+0xab7c90] c2v_resolveInvokeDynamicInPool(JNIEnv_*, _jobject*, _jobject*, long, int)+0x1c8
j jdk.vm.ci.hotspot.CompilerToVM.resolveInvokeDynamicInPool(Ljdk/vm/ci/hotspot/HotSpotConstantPool;JI)V+0 jdk.internal.vm.ci@21-ea
j jdk.vm.ci.hotspot.CompilerToVM.resolveInvokeDynamicInPool(Ljdk/vm/ci/hotspot/HotSpotConstantPool;I)V+7 jdk.internal.vm.ci@21-ea
j jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(IIZ)V+173 jdk.internal.vm.ci@21-ea
j com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(Ljdk/vm/ci/meta/ConstantPool;IIZ)V+32 org.graalvm.nativeimage.pointsto
j com.oracle.graal.pointsto.phases.NoClassInitializationPlugin.loadReferencedType(Lorg/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderContext;Ljdk/vm/ci/meta/ConstantPool;II)V+5 org.graalvm.nativeimage.pointsto
The above crash was produced with a slowdebug build based on openjdk 787832a58677205c9a11ae100dd8a2fbddb30a4a with the following patch:
===========================================
diff --git a/src/hotspot/share/oops/constantPool.hpp b/src/hotspot/share/oops/constantPool.hpp
index 93a4f504448..e33fe336d05 100644
--- a/src/hotspot/share/oops/constantPool.hpp
+++ b/src/hotspot/share/oops/constantPool.hpp
@@ -253,7 +253,7 @@ class ConstantPool : public Metadata {
// The main reason is that byte swapping is sometimes done on normal indexes.
// Finally, it is helpful for debugging to tell the two apart.
static bool is_invokedynamic_index(int i) { return (i < 0); }
- static int decode_invokedynamic_index(int i) { assert(is_invokedynamic_index(i), ""); return ~i; }
+ static int decode_invokedynamic_index(int i) { assert(is_invokedynamic_index(i), "i=%d", i); return ~i; }
static int encode_invokedynamic_index(int i) { assert(!is_invokedynamic_index(i), ""); return ~i; }
// Given the per-instruction index of an indy instruction, report the
===========================================
To reproduce:
jdk/open> git checkout 787832a58677205c9a11ae100dd8a2fbddb30a4a
jdk/open> make graal-builder-image
jdk/open> export JAVA_HOME=$PWD/build/*/images/graal-builder-jdk
> git clone https://github.com/graalvm/mx.git
> export MX_PYTHON=python3.8. # Ensure python3.8 is on PATH
> export PATH=$PWD/mx:$PATH
> git clone https://github.com/oracle/graal.git
> cd graal
> cd git reset --hard de7a57939aa17b069f22f49b7bd6cb0941c3153f
> cd vm
mx --env libgraal build
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/Users/dnsimon/dev/jdk-jdk/open/src/hotspot/share/oops/constantPool.hpp:256), pid=30379, tid=9219
# assert(is_invokedynamic_index(i)) failed: i=8
#
Stack: [0x000000016ef70000,0x000000016f973000], sp=0x000000016f96d2e0, free space=10228k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x112dcdc] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x990 (con
stantPool.hpp:256)
V [libjvm.dylib+0x112e32c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x68
V [libjvm.dylib+0x5d6358] report_vm_error(char const*, int, char const*, char const*, ...)+0x60
V [libjvm.dylib+0x5af0] ConstantPool::decode_invokedynamic_index(int)+0x60
V [libjvm.dylib+0xc6ed58] LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x44
V [libjvm.dylib+0xc6e834] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0x134
V [libjvm.dylib+0xab7c90] c2v_resolveInvokeDynamicInPool(JNIEnv_*, _jobject*, _jobject*, long, int)+0x1c8
j jdk.vm.ci.hotspot.CompilerToVM.resolveInvokeDynamicInPool(Ljdk/vm/ci/hotspot/HotSpotConstantPool;JI)V+0 jdk.internal.vm.ci@21-ea
j jdk.vm.ci.hotspot.CompilerToVM.resolveInvokeDynamicInPool(Ljdk/vm/ci/hotspot/HotSpotConstantPool;I)V+7 jdk.internal.vm.ci@21-ea
j jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(IIZ)V+173 jdk.internal.vm.ci@21-ea
j com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(Ljdk/vm/ci/meta/ConstantPool;IIZ)V+32 org.graalvm.nativeimage.pointsto
j com.oracle.graal.pointsto.phases.NoClassInitializationPlugin.loadReferencedType(Lorg/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderContext;Ljdk/vm/ci/meta/ConstantPool;II)V+5 org.graalvm.nativeimage.pointsto
The above crash was produced with a slowdebug build based on openjdk 787832a58677205c9a11ae100dd8a2fbddb30a4a with the following patch:
===========================================
diff --git a/src/hotspot/share/oops/constantPool.hpp b/src/hotspot/share/oops/constantPool.hpp
index 93a4f504448..e33fe336d05 100644
--- a/src/hotspot/share/oops/constantPool.hpp
+++ b/src/hotspot/share/oops/constantPool.hpp
@@ -253,7 +253,7 @@ class ConstantPool : public Metadata {
// The main reason is that byte swapping is sometimes done on normal indexes.
// Finally, it is helpful for debugging to tell the two apart.
static bool is_invokedynamic_index(int i) { return (i < 0); }
- static int decode_invokedynamic_index(int i) { assert(is_invokedynamic_index(i), ""); return ~i; }
+ static int decode_invokedynamic_index(int i) { assert(is_invokedynamic_index(i), "i=%d", i); return ~i; }
static int encode_invokedynamic_index(int i) { assert(!is_invokedynamic_index(i), ""); return ~i; }
// Given the per-instruction index of an indy instruction, report the
===========================================
To reproduce:
jdk/open> git checkout 787832a58677205c9a11ae100dd8a2fbddb30a4a
jdk/open> make graal-builder-image
jdk/open> export JAVA_HOME=$PWD/build/*/images/graal-builder-jdk
> git clone https://github.com/graalvm/mx.git
> export MX_PYTHON=python3.8. # Ensure python3.8 is on PATH
> export PATH=$PWD/mx:$PATH
> git clone https://github.com/oracle/graal.git
> cd graal
> cd git reset --hard de7a57939aa17b069f22f49b7bd6cb0941c3153f
> cd vm
mx --env libgraal build
- relates to
-
JDK-8301995 Move invokedynamic resolution information out of ConstantPoolCacheEntry
-
- Resolved
-