Details
-
Bug
-
Resolution: Fixed
-
P3
-
11, 12, 13
-
b20
-
generic
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8226505 | 11.0.5-oracle | Xin Liu | P3 | Resolved | Fixed | b02 |
JDK-8225722 | 11.0.5 | Xin Liu | P3 | Resolved | Fixed | b01 |
JDK-8225327 | openjdk8u222 | Xin Liu | P3 | Resolved | Fixed | b05 |
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.
[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.
Attachments
Issue Links
- backported by
-
JDK-8225327 pathological case of JIT recompilation and code cache bloat
- Resolved
-
JDK-8225722 pathological case of JIT recompilation and code cache bloat
- Resolved
-
JDK-8226505 pathological case of JIT recompilation and code cache bloat
- Resolved
- relates to
-
JDK-8245801 StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!"
- Resolved
-
JDK-8223537 testlibrary_tests/ctw/ClassesListTest.java fails with Agent timeout frequently
- Closed