RFR: 8320237 C2: late inlining of method handle invoke causes duplicate lines in PrintInlining output

Kangcheng Xu kxu at openjdk.org
Wed Jan 10 22:23:23 UTC 2024


On Wed, 10 Jan 2024 08:13:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This PR resolves [JDK-8320237](https://bugs.openjdk.org/browse/JDK-8320237)
>> 
>> The original behavior produces both a failure and success message upon late inlining which is confusing. The patch removes the failure message if inlining was successful. Huge thanks to @rwestrel for reporting and working out a solution.
>> 
>> Unit test `test/hotspot/jtreg/compiler/inlining/TestDuplicatedLateInliningOutput.java` is added and passing.
>
> `compiler/print/PrintInlining.java` fails with `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation`:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (workspace/open/src/hotspot/share/opto/compile.cpp:4601), pid=418042, tid=418058
> #  assert(_print_inlining_stream->size() > 0) failed: missing inlining msg
> #
> # JRE version: Java(TM) SE Runtime Environment (23.0) (fastdebug build 23-internal-2024-01-10-0732483.tobias.hartmann.jdk2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-internal-2024-01-10-0732483.tobias.hartmann.jdk2, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x9db4e6]  Compile::print_inlining_update_delayed(CallGenerator*)+0x1c6
> 
> Current CompileTask:
> C2:643  171    b  4       java.lang.String::substring (58 bytes)
> 
> Stack: [0x00007f59706d4000,0x00007f59707d4000],  sp=0x00007f59707cf220,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x9db4e6]  Compile::print_inlining_update_delayed(CallGenerator*)+0x1c6  (compile.cpp:4601)
> V  [libjvm.so+0x844d7e]  CallGenerator::do_late_inline_helper()+0x8ee  (callGenerator.cpp:687)
> V  [libjvm.so+0x9e1a52]  Compile::inline_boxing_calls(PhaseIterGVN&)+0xc2  (compile.cpp:2026)
> V  [libjvm.so+0x9e42e3]  Compile::Optimize()+0x583  (compile.cpp:2276)
> V  [libjvm.so+0x9e81a4]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1b44  (compile.cpp:860)
> V  [libjvm.so+0x83d245]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1d5  (c2compiler.cpp:142)
> V  [libjvm.so+0x9f3bbc]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x92c  (compileBroker.cpp:2299)
> V  [libjvm.so+0x9f4848]  CompileBroker::compiler_thread_loop()+0x468  (compileBroker.cpp:1958)
> V  [libjvm.so+0xeb98ec]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:721)
> V  [libjvm.so+0x179b586]  Thread::call_run()+0xb6  (thread.cpp:220)
> V  [libjvm.so+0x14a8d47]  thread_native_entry(Thread*)+0x127  (os_linux.cpp:789)
> 
> 
> `compiler/cha/StrengthReduceInterfaceCall.java` and `compiler/ciReplay/TestIncrementalInlining.java` fail as well.

@TobiHartmann Thanks for the report.

The tests were crashing in fastdebug config with or without those specific flags. The latest commit should fix the problem. Please take a look. Thank you very much.

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

PR Comment: https://git.openjdk.org/jdk/pull/17147#issuecomment-1885834913


More information about the hotspot-compiler-dev mailing list