Bug ID: JDK-8137095 [JVMCI] CompilerToVM method "resolveInvokeDynamicInPool" does not work as expected

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

The jdk.internal.jvmci.hotspot.CompilerToVM method "resolveInvokeDynamicInPool" does not work as expected.

Javadoc says: "Ensures that the type referenced by the specified JVM_CONSTANT_InvokeDynamic entry at index cpi in constantPool is loaded and initialized. The behavior of this method is undefined if cpi does not denote a JVM_CONSTANT_InvokeDynamic entry."

That means the method is expected to work if we pass index denoting a JVM_CONSTANT_InvokeDynamic entry.

But actual behavior is JVM crash.

We have constant pool containing:
  #26 = InvokeDynamic      #0:#91        // #0:run:(Lcompiler/jvmci/compilerToVM/test/MultipleImplementer2;)Ljava/lang/Runnable;

We use resolveInvokeDynamicInPool(constantPool, 26) and get crash:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc7453e1c45, pid=26548, tid=26574
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-kshefov_2015_09_24_11_50-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-kshefov_2015_09_24_11_50-b00, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4efc45]  CompilationPolicy::must_be_compiled(methodHandle, int)+0x15
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/kshefov/JTwork/scratch/core.26548)
#
# An error report file with more information is saved as:
# /home/kshefov/JTwork/scratch/hs_err_pid26548.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#


Test cases attached, just apply "ResolveInvokeDynamicInPoolTest.patch" to the clone of http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot and run test with JTREG: 
test/compiler/jvmci/CompilerToVM/ResolveInvokeDynamicInPoolTest.java

[~never], since it's the compiler test, it should be in 'compiler' sub-component.
25-06-2018
This is indeed another case of mistaking the `cpi` argument in to be a constant pool index from the original class file as opposed to a constant pool index decoded from a bytecode instruction stream. The JVMCI ConstantPool class is tightly coupled to the state of the bytecode stream after any rewriting that may have been done by the VM. That is why is simply doesn't make sense to test the CompilerToVM methods that take a "constant pool index" argument and expect it to work with an original class file constant pool index. I admit this could have been documented more clearly in the JVMCI javadoc. However, we never intended for CompilerToVM to be exposed as a part of the public JVMCI API and only later managed to make it completely package private to ensure this. In this context, I suggest the ResolveInvokeDynamicInPoolTest.java test be discarded or rewritten to only use a `cpi` value read from the bytecode stream associated with the ConstantPool object under test.
16-09-2016
attached updated version of this test
16-09-2016
Re-assigned back to reporter until test compiles and runs.
08-09-2016
ILW = crash; specific JVMCI internal class usage; none = HLH = P2
08-06-2016
If someone updates the test so that it compiles and runs, I can investigate this further.
13-05-2016
The test could be integrated together with the fix.
13-05-2016
The test for this exists only as the attached patch. Presumably the test should pass before it's integrated?
13-05-2016
Can we just close this one?
11-01-2016
ResolveInvokeDynamicInPoolTest.java seems to no longer exist.
18-11-2015
Where do we stand with this one?
18-11-2015
Constant pool index is correct. The problem is that method crashes, if invokeDynamic is not compiled. I suggest to throw an Exception in this case to avoid crash.
09-10-2015
This looks another case of mistaking cpi to be a constant pool index from the original class file. If you run with a slowdebug VM, you should hit assertions showing this.
24-09-2015
For stack trace please see attached hs_err_pid17302.log
24-09-2015
What's the stack trace?
24-09-2015