-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 8
-
Component/s: hotspot
We observed a deoptimization storm caused by GraphKit::uncommon_trap generator logic. GraphKit::uncommon_trap considers the too_many_recompiles metric. If the threshold is overflowed, it replaces Deoptimization::Action_reinterpret with Deoptimization::Action_none.
This replacement changes the uncommon_trap logic: once execution hits a trap, the VM performs deoptimization but does not recompile the method anymore. In an "unlucky" case, when the code part calling this uncommon_trap becomes frequent, a deoptimization storm occurs (thousands of deoptimizations per second) causing a significant performance drop.
The original problematic repeatedly recompiled method is a high-performance compressed binary serialization algorithm with heavy use of conditional IF blocks driven by bitmasks. See a standalone synthetic benchmark to reproduce the issue.
This replacement changes the uncommon_trap logic: once execution hits a trap, the VM performs deoptimization but does not recompile the method anymore. In an "unlucky" case, when the code part calling this uncommon_trap becomes frequent, a deoptimization storm occurs (thousands of deoptimizations per second) causing a significant performance drop.
The original problematic repeatedly recompiled method is a high-performance compressed binary serialization algorithm with heavy use of conditional IF blocks driven by bitmasks. See a standalone synthetic benchmark to reproduce the issue.
- relates to
-
JDK-6529811 LogCompilation shows infinite repetition of uncommon_trap action='none'
-
- Resolved
-
- links to
-
Review(master)
openjdk/jdk/28966