JDK-8237375 : SimpleThresholdPolicy misses CounterDecay timestamp initialization
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-16
  • Updated: 2020-06-01
  • Resolved: 2020-01-23
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 14 JDK 15
11.0.7Fixed 14.0.1Fixed 15 b08Fixed
Related Reports
Relates :  
JDK-8239466 - Loss of precision in counter decay calculation in 11u backport of JDK-8237375
Description
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.
Comments
Fix request (11u, 14u) Requesting this fix to repair a problem that manifests in jtreg test failures on one of our s/390 linux machines. The patch did not apply, neither to 11u nor to 14u. I've run RFRs and got a review for both: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002496.html The patch runs through SAP's CI without regressions spotted.
14-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/2a0e2304e68b User: mdoerr Date: 2020-01-23 12:56:05 +0000
23-01-2020