JDK-8245801 : StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,13,14,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-05-26
  • Updated: 2022-04-19
  • Resolved: 2020-05-27
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 11 JDK 13 JDK 15
11.0.9-oracleFixed 13.0.7Fixed 15 b25Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/oracle/jdk_jdk/open/src/hotspot/share/oops/instanceKlass.cpp:3091), pid=17897, tid=17909
#  assert(prev == __null || !prev->is_in_use()) failed: redundunt OSR recompilation detected. memory leak in CodeCache!
#
# JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-05-26-1033362.tobias...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-05-26-1033362.tobias..., compiled mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xc9c354]  InstanceKlass::add_osr_nmethod(nmethod*)+0x314
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /oracle/jdk_jdk/open/core.17897)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -XX:+StressRecompilation -Xcomp 

Host: prometheus, Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz, 8 cores, 15G, Ubuntu 18.04.4 LTS
Time: Tue May 26 14:27:41 2020 CEST elapsed time: 6.087660 seconds (0d 0h 0m 6s)

---------------  T H R E A D  ---------------

Current thread (0x00007f7dac342950):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=17909, stack(0x00007f7d67eff000,0x00007f7d68000000)]


Current CompileTask:
C2:   6087 1879 %  b  4       java.lang.StringLatin1::hashCode @ 10 (42 bytes)

Stack: [0x00007f7d67eff000,0x00007f7d68000000],  sp=0x00007f7d67ffb2e0,  free space=1008k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc9c354]  InstanceKlass::add_osr_nmethod(nmethod*)+0x314
V  [libjvm.so+0x7d2c3c]  ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0xfec
V  [libjvm.so+0x13c08ad]  PhaseOutput::install_code(ciMethod*, int, AbstractCompiler*, bool, bool, RTMState)+0x17d
V  [libjvm.so+0x13c0aa4]  PhaseOutput::install()+0x164
V  [libjvm.so+0x8f90d1]  Compile::Code_Gen()+0x461
V  [libjvm.so+0x8ff50e]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x168e
V  [libjvm.so+0x74c6e5]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x175
V  [libjvm.so+0x90dcde]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x45e
V  [libjvm.so+0x90f378]  CompileBroker::compiler_thread_loop()+0x6b8
V  [libjvm.so+0x1693cdc]  JavaThread::thread_main_inner()+0x21c
V  [libjvm.so+0x1699b00]  Thread::call_run()+0x100
V  [libjvm.so+0x139f0d6]  thread_native_entry(Thread*)+0x116

Comments
Fix request (13u) -- will label after testing completed. I would like to backport the fix to jdk13u for parity with jdk11u. The original patch applied cleanly.
19-02-2021

Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.9-oracle. Applies clean.
22-06-2020

Okay, thanks for the information!
29-05-2020

hi, Tobias, Thank you to fix this problem. I am sorry I didn't think of StressRecompilation in the first place. TBH, I don't know that flag until you send the webrev. I can't reproduce the issue using your testcase. it's a timing issue. it's because I can't trigger the OSR compilation of StringLatin1::hashCode neither on my macos laptop nor on Linux server. I made a little bit improvement in your testcase. it can reproduce this issue on my side. just leave it as a note. diff -r f1f88e6fad02 test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java --- a/test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java Thu May 28 22:34:02 2020 -0400 +++ b/test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java Fri May 29 02:01:36 2020 -0700 @@ -32,9 +32,17 @@ package compiler.c2; +import java.util.Random; + public class TestStressRecompilation { public static void main(String[] args) { - System.out.println("Test passed."); + StringBuilder sb = new StringBuilder(); + char[] charset = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i'}; + Random r = new Random(); + for (int i=0; i<20_000; ++i) { + sb.append(charset[r.nextInt(charset.length)]); + } + System.out.println("Test passed." + sb.toString().hashCode()); } }
29-05-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/be37b8884373 User: thartmann Date: 2020-05-27 11:26:46 +0000
27-05-2020

http://cr.openjdk.java.net/~thartmann/8245801/webrev.00/
26-05-2020

Assert was introduced by JDK-8222670.
26-05-2020

ILW = Assert due to unexpected re-compilation of OSR method (false-positive), with debug option, no workaround = MLH = P4
26-05-2020