-
Bug
-
Resolution: Fixed
-
P3
-
11, 14, 15
-
b08
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8239465 | 14.0.2 | Martin Doerr | P3 | Resolved | Fixed | b01 |
| JDK-8239935 | 14.0.1 | Martin Doerr | P3 | Resolved | Fixed | b06 |
| JDK-8239238 | 11.0.8-oracle | Martin Doerr | P3 | Resolved | Fixed | b01 |
| JDK-8239078 | 11.0.7 | Martin Doerr | P3 | Resolved | Fixed | b04 |
Invocation counters always decay at the first safepoint regardless of CounterDecayMinIntervalLength when using SimpleThresholdPolicy (-XX:-TieredCompilation).
This leads to warmup issues (e.g. observed in compiler/c2/Test8004741.java). Some methods don't get compiled as early as expected after the first safepoint.
Reason:
SimpleThresholdPolicy uses a dedicated class CounterDecay which contains a static timestamp. The timestamp is initialized to 0 and is_decay_needed() compares it to the current time.
This leads to warmup issues (e.g. observed in compiler/c2/Test8004741.java). Some methods don't get compiled as early as expected after the first safepoint.
Reason:
SimpleThresholdPolicy uses a dedicated class CounterDecay which contains a static timestamp. The timestamp is initialized to 0 and is_decay_needed() compares it to the current time.
- backported by
-
JDK-8239078 SimpleThresholdPolicy misses CounterDecay timestamp initialization
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Resolved
-