JDK-8306768 : CodeCache Analytics reports wrong threshold
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,19
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2023-04-24
  • Updated: 2023-05-09
  • Resolved: 2023-04-26
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 17
11.0.20Fixed 17.0.8 b01Fixed
Related Reports
Relates :  
Relates :  
Description
https://github.com/openjdk/jdk17u-dev/blob/f969f811a71603f39e4ab42f1362271b7a4d303d/src/hotspot/share/code/codeHeapState.cpp#L1155

Jcmd CodeCache_Analytics uses own implementation of threshold calculation, allowing an error to creep in, making report invalid. Instead of unallocated size, it uses uncommitted size. The problem especially visialbe with InitialCodeCacheSize == ReservedCodeCacheSize. 

https://github.com/openjdk/jdk17u-dev/blob/f969f811a71603f39e4ab42f1362271b7a4d303d/src/hotspot/share/code/codeCache.cpp#L926

{code}
java -XX:InitialCodeCacheSize=1G -XX:ReservedCodeCacheSize=1G Sleep.java

jcmd jdk.compiler/com.sun.tools.javac.launcher.Main  Compiler.CodeHeap_Analytics | grep -A 2 "Threshold for method to be considered 'cold'"
Threshold for method to be considered 'cold': 5330737152.000
min. hotness =   1016
avg. hotness =   2048
--
Threshold for method to be considered 'cold': 5330696192.000
min. hotness =   1016
avg. hotness =   2048
--
Threshold for method to be considered 'cold': 75978752.000
No hotness data available
{code}


Comments
Changeset: 243e6430 Author: Anton Kozlov <akozlov@openjdk.org> Committer: Paul Hohensee <phh@openjdk.org> Date: 2023-04-26 11:44:03 +0000 URL: https://git.openjdk.org/jdk17u/commit/243e643076f70c2cfb480897e1640a21e7ac6552
03-05-2023

Changeset: 243e6430 Author: Anton Kozlov <akozlov@openjdk.org> Committer: Paul Hohensee <phh@openjdk.org> Date: 2023-04-26 11:44:03 +0000 URL: https://git.openjdk.org/jdk17u-dev/commit/243e643076f70c2cfb480897e1640a21e7ac6552
26-04-2023

Fix Request 11u: Backport from 17u, same motivation. The backport is not clean because of difference in parameters in 11 and 17. The code in 11 made aligned with sweeper logic. The change tested manually.
26-04-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1295 Date: 2023-04-25 09:06:28 +0000
25-04-2023

Does not affect latest JDK since the statistic was removed with the removal of the sweeper (JDK-8290025). ILW = Wrong statistics printed for code cache, medium?, no workaround = LMH = P5
25-04-2023

Fix Request 17u: This is an original fix that replaced ad-hoc threshold calculation in jcmd reporting with a method call used in the runtime code. The value is inteded for human eyes and now that is correct, verified manually.
25-04-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1849 Date: 2023-04-24 17:19:30 +0000
24-04-2023

The suggested fix is to use the same method for free ratio calculation that is used by the sweeper. The change touches reporting code only, so the risk is not that high, althought the fix is not a backport.
24-04-2023

The code was removed in JDK-8290025, but still lives in update releases.
24-04-2023