Bug ID: JDK-8275830 C2: Receiver downcast is missing when inlining through method handle linkers

JDK-8275830 : C2: Receiver downcast is missing when inlining through method handle linkers

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 17,18

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2021-10-23
Updated: 2022-03-07
Resolved: 2022-01-04

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.

JDK 17	JDK 18	JDK 19
17.0.4-oracleFixed	18 b30Fixed	19Fixed

Related Reports

Relates :	JDK-8280467 - C1: Perform CHA when inlining through method handle linkers
Relates :	JDK-8267807 - C2: Downcast receiver to target holder during inlining
Relates :	JDK-8268405 - Several regressions 4-17% after CHA changes
Relates :	JDK-8280469 - No CHA for interface calls when inlining through method handle linker

Description

Seen in developer testing only (so far), and only with this one test.

Current CompileTask:
C2:  95948 4127       4       java.lang.invoke.LambdaForm$MH/0x00000001001af400::invoke (71 bytes)

Stack: [0x00007f98cebfc000,0x00007f98cecfd000],  sp=0x00007f98cecf8eb0,  free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x15b1811]  Parse::do_method_entry()+0x431
V  [libjvm.so+0x15baf14]  Parse::Parse(JVMState*, ciMethod*, float)+0x9b4
V  [libjvm.so+0x820ce0]  ParseGenerator::generate(JVMState*)+0x110
V  [libjvm.so+0xb50461]  Parse::do_call()+0x371
V  [libjvm.so+0x15c71e8]  Parse::do_one_bytecode()+0x428
V  [libjvm.so+0x15b53c8]  Parse::do_one_block()+0x838
V  [libjvm.so+0x15b62f0]  Parse::do_all_blocks()+0x130
V  [libjvm.so+0x15bb0f5]  Parse::Parse(JVMState*, ciMethod*, float)+0xb95
V  [libjvm.so+0x820ce0]  ParseGenerator::generate(JVMState*)+0x110
V  [libjvm.so+0xb50461]  Parse::do_call()+0x371
V  [libjvm.so+0x15c71e8]  Parse::do_one_bytecode()+0x428
V  [libjvm.so+0x15b53c8]  Parse::do_one_block()+0x838
V  [libjvm.so+0x15b62f0]  Parse::do_all_blocks()+0x130
V  [libjvm.so+0x15bb0f5]  Parse::Parse(JVMState*, ciMethod*, float)+0xb95
V  [libjvm.so+0x820ce0]  ParseGenerator::generate(JVMState*)+0x110
V  [libjvm.so+0xa02f62]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x1342
V  [libjvm.so+0x81dd36]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x646
V  [libjvm.so+0xa135f9]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd09
V  [libjvm.so+0xa14298]  CompileBroker::compiler_thread_loop()+0x518
V  [libjvm.so+0x18896ec]  JavaThread::thread_main_inner()+0x27c
V  [libjvm.so+0x188fca0]  Thread::call_run()+0x100
V  [libjvm.so+0x156f5e4]  thread_native_entry(Thread*)+0x104

Comments

Fix Request (17u): Should get backported for parity with 17.0.4-oracle. Applies cleanly. No new test failures observed (our nightly tests).
05-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/197 Date: 2022-03-04 11:57:25 +0000
04-03-2022
Changeset: 95a3010a Author: Vladimir Ivanov <vlivanov@openjdk.org> Date: 2022-01-04 12:35:48 +0000 URL: https://git.openjdk.java.net/jdk/commit/95a3010acf822a76bf0e1ebffdddce5d38b75e7b
04-01-2022
Changeset: 95a3010a Author: Vladimir Ivanov <vlivanov@openjdk.org> Date: 2022-01-04 12:35:48 +0000 URL: https://git.openjdk.java.net/jdk18/commit/95a3010acf822a76bf0e1ebffdddce5d38b75e7b
04-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk18/pull/77 Date: 2022-01-03 18:45:25 +0000
03-01-2022
[~dlong] yes, your analysis is correct: the problem is JDK-8268405 fix works only for invokevirtual/invokeinterface bytecodes and not when invocation happens through method handle linkers (MH.linkToVirtual/linkToInterface).
03-01-2022
I haven't been able to reproduce this, but I think I see the problem. We aren't calling HeapFloatBuffer::put with an invokevirtual bytecode. We are actually doing something like this: 14: invokestatic #24 // Method java/lang/invoke/MethodHandle.linkToVirtual:(Ljava/lang/Object;IDLjava/lang/invoke/MemberName;)Ljava/lang/Object; which is processed by CallGenerator::for_method_handle_inline. Finally, we call call_generator() with the resolved callee, but the bci is still 14, pointing at an invokestatic. So this new code from JDK-8268405 does not work as intended: const bool is_virtual_or_interface = (bytecode == Bytecodes::_invokevirtual) \|\| (bytecode == Bytecodes::_invokeinterface); [...] if (cg != NULL && is_virtual_or_interface && !callee->is_static()) { CallGenerator* trap_cg = CallGenerator::for_uncommon_trap(callee, To make this work with linkToVirtual and friends, I think we need to pass in the bytecode value (real or emulated) as an argument.
19-12-2021
I forgot to mention, I tried to use SA to generate the dynamic class files from two of the core dumps, but it failed, so I wasn't able to try replay on the failures.
17-12-2021
We had a similar crash on darwinaarch64 on Nov 26th in OpenJDK18 (again in the java/nio/Buffer/EqualsCompareTest.java test). The fastdbg JVM was used to get the assertion. We run jtreg_jdk_tier1 to see this crash (probably you have to run that suite a few 100 times to reproduce the issue). So at least at that time the issue was present. (Previous crash I reported was from linux x86_64) . # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/openjdk/nb/darwinaarch64/jdk/src/hotspot/share/opto/parse1.cpp:1210), pid=60744, tid=23555 # assert(callee_holder->is_interface()) failed: missing subtype check # Host: mymac1, "Macmini9,1" arm64, 8 cores, 16G, Darwin 20.6.0, macOS 11.6.1 Time: Fri Nov 26 01:21:52 2021 CET elapsed time: 4.099362 seconds (0d 0h 0m 4s) --------------- T H R E A D --------------- Current thread (0x0000000139045e20): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=23555, stack(0x000000016d550000,0x000000016d753000)] Current CompileTask: C2: 4099 1839 4 java.lang.invoke.LambdaForm$MH/0x0000000800c94c00::invoke (71 bytes) Stack: [0x000000016d550000,0x000000016d753000], sp=0x000000016d74fae0, free space=2046k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x113fc98] VMError::report_and_die(int, char const, char const, char, Thread, unsigned char, void, void, char const, int, unsigned long)+0x5d0 V [libjvm.dylib+0x11403d0] VMError::report_and_die(Thread, void, char const, int, char const, char const, char)+0x40 V [libjvm.dylib+0x59dc18] report_vm_error(char const, int, char const, char const, ...)+0x80 V [libjvm.dylib+0xdc73cc] Parse::do_method_entry()+0x238 V [libjvm.dylib+0xdc56c8] Parse::Parse(JVMState, ciMethod, float)+0x9bc V [libjvm.dylib+0x448d90] ParseGenerator::generate(JVMState)+0xbc V [libjvm.dylib+0x65bd14] Parse::do_call()+0xb60 V [libjvm.dylib+0xddb5cc] Parse::do_one_bytecode()+0x1cc V [libjvm.dylib+0xdcb7f8] Parse::do_one_block()+0x3f0 V [libjvm.dylib+0xdc984c] Parse::do_all_blocks()+0x330 V [libjvm.dylib+0xdc58d0] Parse::Parse(JVMState, ciMethod, float)+0xbc4 V [libjvm.dylib+0x448d90] ParseGenerator::generate(JVMState)+0xbc V [libjvm.dylib+0x65bd14] Parse::do_call()+0xb60 V [libjvm.dylib+0xddb5cc] Parse::do_one_bytecode()+0x1cc V [libjvm.dylib+0xdcb7f8] Parse::do_one_block()+0x3f0 V [libjvm.dylib+0xdc984c] Parse::do_all_blocks()+0x330 V [libjvm.dylib+0xdc58d0] Parse::Parse(JVMState, ciMethod, float)+0xbc4 V [libjvm.dylib+0x448d90] ParseGenerator::generate(JVMState)+0xbc V [libjvm.dylib+0x547fb0] Compile::Compile(ciEnv, ciMethod, int, Options, DirectiveSet)+0xeb4 V [libjvm.dylib+0x447b44] C2Compiler::compile_method(ciEnv, ciMethod, int, bool, DirectiveSet)+0x160 V [libjvm.dylib+0x563520] CompileBroker::invoke_compiler_on_method(CompileTask)+0x7a0 V [libjvm.dylib+0x562bc0] CompileBroker::compiler_thread_loop()+0x288 V [libjvm.dylib+0x1099944] JavaThread::thread_main_inner()+0x25c V [libjvm.dylib+0x10996c8] JavaThread::run()+0x374 V [libjvm.dylib+0x1096a50] Thread::call_run()+0x21c V [libjvm.dylib+0xd9df54] thread_native_entry(Thread)+0x160 C [libsystem_pthread.dylib+0x7878] _pthread_start+0x140
17-12-2021
Perhaps this happened because of some bug that was introduced and then fixed a short while later? All 4 bugs are with G1.
17-12-2021
I tried to reproduce this but no luck so far. I took a look at one of the core dumps, but didn't anything obviously wrong. I had a theory that CHA decision based on a unique subclass was invalidated by concurrent class loading, but the times in the hs_err file seem to indicate that classloading of the new subclass happened before the compile started.
17-12-2021
The crash happened again in the jtreg test java/nio/Buffer/EqualsCompareTest.java ; unfortunately I have no replay files. Backtrace is : Current CompileTask: C2: 9085 1995 4 java.lang.invoke.LambdaForm$MH/0x0000000800c95000::invoke (71 bytes) Stack: [0x00007f3c67aed000,0x00007f3c67bee000], sp=0x00007f3c67be9f00, free space=1011k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13ce6c4] Parse::do_method_entry()+0x384 V [libjvm.so+0x13d5c95] Parse::Parse(JVMState, ciMethod, float)+0xa45 V [libjvm.so+0x7b544c] ParseGenerator::generate(JVMState)+0x17c V [libjvm.so+0xa8ba08] Parse::do_call()+0x528 V [libjvm.so+0x13e1150] Parse::do_one_bytecode()+0xfc0 V [libjvm.so+0x13d1518] Parse::do_one_block()+0x5f8 V [libjvm.so+0x13d2147] Parse::do_all_blocks()+0x117 V [libjvm.so+0x13d5e90] Parse::Parse(JVMState, ciMethod, float)+0xc40 V [libjvm.so+0x7b544c] ParseGenerator::generate(JVMState)+0x17c V [libjvm.so+0xa8ba08] Parse::do_call()+0x528 V [libjvm.so+0x13e1150] Parse::do_one_bytecode()+0xfc0 V [libjvm.so+0x13d1518] Parse::do_one_block()+0x5f8 V [libjvm.so+0x13d2147] Parse::do_all_blocks()+0x117 V [libjvm.so+0x13d5e90] Parse::Parse(JVMState, ciMethod, float)+0xc40 V [libjvm.so+0x7b544c] ParseGenerator::generate(JVMState)+0x17c V [libjvm.so+0x95493c] Compile::Compile(ciEnv, ciMethod, int, Options, DirectiveSet)+0x174c V [libjvm.so+0x7b1df6] C2Compiler::compile_method(ciEnv, ciMethod, int, bool, DirectiveSet)+0x406 V [libjvm.so+0x9621e9] CompileBroker::invoke_compiler_on_method(CompileTask)+0xbe9 V [libjvm.so+0x962c18] CompileBroker::compiler_thread_loop()+0x3c8 V [libjvm.so+0x17653ab] JavaThread::thread_main_inner()+0x25b V [libjvm.so+0x176b0c8] Thread::call_run()+0xf8 V [libjvm.so+0x1392959] thread_native_entry(Thread*)+0x109
16-11-2021
[~mbaesken] can you share any info? Like what test/tests failed? Replay files?
16-11-2021
We have seen this issue as well today in our central OpenJDK18 jtreg tests (on Linux x86_64, SLES15).
09-11-2021
ILW = C2 assertion failure during parsing, single test intermittent, disable compilation of affected method = HLM = P3
25-10-2021
In the most recent crash on 10/23, holder_type is java/nio/HeapFloatBuffer and receiver_type is java/nio/FloatBuffer. The replay file shows a call to java/nio/HeapFloatBuffer.put() through lambda classes: compile java/lang/invoke/LambdaForm$MH+0x00000001001af400 invoke (Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;)V -1 4 inline 13 0 -1 java/lang/invoke/LambdaForm$MH+0x00000001001af400 invoke (Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;)V 1 8 java/lang/invoke/MethodHandleImpl assertSame (Ljava/lang/Object;Ljava/lang/Object;)V 1 29 @bci SquareRootTests halfWay ()I 130 <appendix> form vmentry <vmtarget> ; invoke (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 2 21 java/lang/invoke/DirectMethodHandle$Holder invokeSpecial (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 3 1 java/lang/invoke/DirectMethodHandle internalMemberName (Ljava/lang/Object;)Ljava/lang/Object; 1 46 java/lang/invoke/LambdaForm$MH+0x00000001001acc00 invoke (Ljava/lang/Object;Ljava/lang/Object;)F 2 21 java/lang/invoke/LambdaForm$DMH+0x00000001001ac000 invokeStatic (Ljava/lang/Object;Ljava/lang/Object;I)F 3 1 java/lang/invoke/DirectMethodHandle internalMemberName (Ljava/lang/Object;)Ljava/lang/Object; 3 11 sun/invoke/util/ValueConversions unboxFloat (Ljava/lang/Object;Z)F 4 11 java/lang/Float floatValue ()F 1 67 java/lang/invoke/LambdaForm$DMH+0x0000000100190400 invokeVirtual (Ljava/lang/Object;Ljava/lang/Object;IF)Ljava/lang/Object; 2 1 java/lang/invoke/DirectMethodHandle internalMemberName (Ljava/lang/Object;)Ljava/lang/Object; 2 14 java/nio/HeapFloatBuffer put (IF)Ljava/nio/FloatBuffer;
23-10-2021