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

[Matias Saavedra Silva]

On Fri, 20 Oct 2023 08:49:22 GMT, Gui Cao <gcao at openjdk.org> wrote:

> 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)
> ```

This issue was the result of a change to include the a union inside `ResolvedMethodEntry`. The most recent commit and merge should have addressed this problem and made the interpreter code stable. Thanks for your patience

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

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