JDK-8137092 : [JVMCI] CompilerToVM methods "lookupNameAndTypeRefIndexInPool" and "lookupKlassRefIndexInPool" do not work as expected
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2015-09-24
  • Updated: 2015-09-24
  • Resolved: 2015-09-24
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.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-8062493 - JEP 243: Java-Level JVM Compiler Interface
Description
The jdk.internal.jvmci.hotspot.CompilerToVM methods "lookupNameAndTypeRefIndexInPool" and "lookupKlassRefIndexInPool" do not work as expected.

Javadoc says: "Gets the JVM_CONSTANT_NameAndType index from the entry at index cpi in constantPool. The behavior of this method is undefined if  cpi does not denote an entry containing a JVM_CONSTANT_NameAndType index."

That means that methods take a constant pool index as their second argument.

The actual behavior is such that these methods use not a standard CPI index, but some bogus index that starts from zero, not one, and has nothing common with standard CPI from JAVAP output.

If we have a constant pool containing:
    #1 = Methodref          #22.#68       // java/lang/Object."<init>":()V
    #4 = Fieldref           #35.#70       // compiler/jvmci/compilerToVM/test/MultipleImplementer2.intField:I
    #7 = Fieldref           #35.#71       // compiler/jvmci/compilerToVM/test/MultipleImplementer2.longField:J
    #9 = Fieldref           #35.#72       // compiler/jvmci/compilerToVM/test/MultipleImplementer2.floatField:F
   #12 = Fieldref           #35.#73       // compiler/jvmci/compilerToVM/test/MultipleImplementer2.doubleField:D

and use method lookupNameAndTypeRefIndexInPool(constantPool, 1),
we, instead of expected "68" number, get number "70", which corresponds to name_and_type from "#4 = Fieldref   #35.#70", not form "#1 = Methodref          #22.#68".

At the same time if we use lookupNameAndTypeRefIndexInPool(constantPool, 0), we get "68" corresponding to #1 = Methodref   #22.#68".

Another two methods "lookupNameInPool" and "lookupSignatureInPool" also do not work with normal CPI as expected just in the same way.
Comments
I'm closing this as Not an Issue.
24-09-2015
If taking cpi not from class file, but from bytecode streams is intended, you are free to close this bug as "not an issue".
24-09-2015
Doug's comment: "The confusion around these constant pool indexes stems from the fact Graal uses the CPI���s read from bytecode streams that have been rewritten (by the VM). These are often very different from the CPIs in the class file".
24-09-2015
It seems that these 4 methods take CPI from VM, not from class file. If so, this may not be actually a bug.
24-09-2015
Tests attached, just apply 8137092Tests.patch to the clone of http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot and run tests with JTREG: test/compiler/jvmci/CompilerToVM/LookupNameAndTypeRefIndexInPoolTest.java test/compiler/jvmci/CompilerToVM/LookupKlassRefIndexInPoolTest.java test/compiler/jvmci/CompilerToVM/LookupNameInPoolTest.java test/compiler/jvmci/CompilerToVM/LookupSignatureInPoolTest.java
24-09-2015