JDK-8222670 : pathological case of JIT recompilation and code cache bloat
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • Submitted: 2019-04-17
  • Updated: 2021-10-12
  • Resolved: 2019-05-07
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 Other
11.0.5-oracleFixed 13 b20Fixed openjdk8u222Fixed
Related Reports
Relates :  
Relates :  
Description
TieredThresholdPolicy::select_task implements a special case of downgrading.

[quote]
  c. 0 -> (3->2) -> 4.
     In this case we enqueue a method for compilation at level 3, but the C1 queue is long enough
     to enable the profiling to fully occur at level 0. In this case we change the compilation level
    of the method to 2 while the request is still in-queue, because it'll allow it to run much faster
    without full profiling while c2 is compiling
[/quote]

A method might downgrade from level-3(CompLevel_full_profile) to level-2(CompLevel_limited_profile). After then, C1 will compile the method and a nmethod will be populated in the code cache.

Because the level-3 method is not seen, the application might trigger level-3 compilation again. CompileBroker::compile_method fails to detect the pre-existing nmethod because comp_level doesn't match. As a result, it will repeat the above procedure.

We observe that some applications will execute this loop thousands of times. 2 negative impacts occur:
1. higher CPU utility for C1 compilation
2. code cache bloat or even overflow

OSR is worse. Because all osr-compiled nmethods are stored in an InstanceKlass in the form of a linked-list, InstanceKlass::lookup_osr_nmethod will degenerate dramatically because of same method recompilation.
Comments
backport to jdk11u. change filenmame simpleThresholdPolicy.cpp from tieredThresholdPolicy.cpp. https://cr.openjdk.java.net/~xliu/8222670/webrev.11u-dev/
07-06-2019

URL: http://hg.openjdk.java.net/jdk/jdk/rev/1dc9bf9d016b User: thartmann Date: 2019-05-07 07:17:27 +0000
07-05-2019

https://cr.openjdk.java.net/~xliu/8222670/webrev.02/
24-04-2019

https://cr.openjdk.java.net/~xliu/8222670/webrev/
18-04-2019

ILW = Redundant recompilation of method, rare but reproducible with test, disable tiered compilation or compilation of affected method = MMH = P3
18-04-2019

check out the lvl2_recomp.log it compiled compiler.whitebox.SimpleTestCaseHelper.method()I 1000 times. only the last one is still on codecache. it compiled compiler.whitebox.SimpleTestCaseHelper.osrStaticMethod(J)I 1000 times. all of them are on codecache.
17-04-2019

to run the testcase above, you need to apply whitebox first. after then, use the following options: -XX:+TieredCompilation \ -XX:+UnlockDiagnosticVMOptions \ -XX:+WhiteBoxAPI \ -XX:-UseCounterDecay \ -XX:CompileCommand=compileonly,compiler.whitebox.SimpleTestCaseHelper::* \ -XX:CompileCommand=print,compiler.whitebox.SimpleTestCaseHelper::* \ -XX:+PrintCodeCache2 \ -XX:+Verbose \
17-04-2019