RFR: 8301997: Move method resolution information out of the cpCache [v3]

[Gui Cao]

On Fri, 20 Oct 2023 03:38:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The current structure used to store the resolution information for methods, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure previously held information for fields, methods, and invokedynamic calls which were all encoded into f1 and f2. Currently this structure only handles method entries, but it remains obtuse and inconsistent with recent changes. 
>> 
>> This enhancement introduces a new data structure that stores the necessary resolution data in an intuitive an extensible manner. These resolved entries are stored in an array inside the constant pool cache in a very similar manner to invokedynamic entries in JDK-8301995.
>> 
>> Instances of ConstantPoolCache entry related to field resolution have been replaced with the new ResolvedMethodEntry, and ConstantPoolCacheEntry has been removed entirely. The class ResolvedMethodEntry holds resolution information for all types of invoke calls besides invokedynamic, and thus has fields that may be unused depending on the invoke code. 
>> 
>> To streamline the review, please consider these major areas that have been changed:
>> 1. ResolvedMethodEntry class
>> 2. Rewriter for initialization of the structure
>> 3. cpCache for resolution
>> 4. InterpreterRuntime, linkResolver, and templateTable
>> 5. JVMCI
>> 6. SA
>> 
>> Verified with tier 1-9 tests.
>> 
>> This change supports the following platforms: x86, aarch64
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed dead code in interpreters
>  - Removed unused structures, improved set_method_handle and appendix_if_resolved

Hello, I'm preparing the riscv part of the support, but I noticed that the x86 backend is reporting errors.

zifeihan at plct-c8:~/jdk$ make test TEST="tier1" JTREG="TIMEOUT_FACTOR=16"
Building target 'test' in configuration 'linux-x86_64-server-release'
Running tests using JTREG control variable 'TIMEOUT_FACTOR=16'
Test selection 'tier1', will run:
* jtreg:test/hotspot/jtreg:tier1
* jtreg:test/jdk:tier1
* jtreg:test/langtools:tier1
* jtreg:test/jaxp:tier1
* jtreg:test/lib-test:tier1

Running test 'jtreg:test/hotspot/jtreg:tier1'
An exception has occurred in the compiler (22-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(VarHandle,byte[],int)long to (VarHandle,byte[],int)int
	at java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:903)
	at java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:870)
	at java.base/jdk.internal.util.ByteArray.getLong(ByteArray.java:188)
	at java.base/java.io.DataInputStream.readLong(DataInputStream.java:408)
	at jdk.compiler/com.sun.tools.javac.util.ByteBuffer.getLong(ByteBuffer.java:211)
	at jdk.compiler/com.sun.tools.javac.jvm.PoolReader.resolve(PoolReader.java:260)
	at jdk.compiler/com.sun.tools.javac.jvm.PoolReader$ImmutablePoolHelper.readIfNeeded(PoolReader.java:391)
	at jdk.compiler/com.sun.tools.javac.jvm.PoolReader.getConstant(PoolReader.java:206)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader$3.read(ClassReader.java:855)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1433)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readMemberAttrs(ClassReader.java:1423)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readField(ClassReader.java:2283)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2645)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2738)
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2762)
	at jdk.compiler/com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:373)
	at jdk.compiler/com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:302)
	at jdk.compiler/com.sun.tools.javac.code.Symtab$2.complete(Symtab.java:360)
	at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:682)
	at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1418)
	at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:1334)
	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2183)
	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2159)
	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1050)
	at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4894)
	at jdk.compiler/com.sun.tools.javac.code.Types.asSuper(Types.java:2156)
	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2179)
	at jdk.compiler/com.sun.tools.javac.code.Types$12.visitClassType(Types.java:2159)
	at jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1050)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15455#issuecomment-1772334734