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.