JDK-8241678 : Remove PerfData sampling via StatSampler
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8,11,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-03-26
  • Updated: 2025-06-27
  • Resolved: 2025-05-28
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 25
25 b26Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Sub Tasks
JDK-8355937 :  
Description
PerfData contains a periodic task (the StatSampler) the samples and writes a small number of counters to the PerfData file. This mechanism was introduced many years ago but has remained largely unused and redundant.
- For G1 and ZGC, it only records the current time.
- For Serial and Parallel, it updates heap usage counters, but these are already updated after each GC cycle.
- The sampled timestamp is rarely used.
- The controlling flag, -XX:PerfDataSamplingInterval is obscure and poorly documented.
This functionality adds overhead and complexity for little to no benefit.

This change removes the following:
- The StatSampler periodic task.
- The associated sampling logic in PerfData
- The -XX:PerfDataSamplingInterval flag, which is obsoleted in JDK 25, marked for removal in JDK 26.

In addition:
- The sun.os.hrt.ticks PerfData counter (the sampled timestamp), has been removed.
- jstat -t has been updated to compute current timestamps instead of relying on the sampled timestamp.
- The Eden usage counter for Serial and Parallel will always report 0, since eden is empty after each collection.


This change only affects tools that read directly from the PerfData file, such as jstat. Other monitoring tools relying on other mechanisms remain unaffected.

Using the flag in JDK 25 will produce an error:
java -XX:PerfDataSamplingInterval=10 --version
OpenJDK 64-Bit Server VM warning: Ignoring option PerfDataSamplingInterval; support was removed in 25.0

And will not work in JDK 26 onwards:
java -XX:PerfDataSamplingInterval=10 --version
Unrecognized VM option 'PerfDataSamplingInterval=10'
Comments
@cnorrbin the PerfDataSamplingIntervalFunc function should also have been removed as part of this. I've filed JDK-8358891
09-06-2025

Changeset: 6ebae6cd Branch: master Author: Casper Norrbin <cnorrbin@openjdk.org> Committer: Albert Mingkun Yang <ayang@openjdk.org> Date: 2025-05-28 12:00:15 +0000 URL: https://git.openjdk.org/jdk/commit/6ebae6cded49f9b0b0d42899af3303647eca7848
28-05-2025

No counter has been removed—only its periodic sampling. The consequence being that eden usage will report as 0 for Serial/Parallel because they only update the counters after each cycle. jstat is the only tool relying on these perfdata counters. It is hard to say if the reported eden-usage was useful to begin with, as it depends entirely on the sampling instant. Given that jstat is an aging tool with limited use today, this change is unlikely to pose any real risk. Importantly, the underlying information is still available and can be accessed through other mechanisms that don’t rely on perfdata. Tools like GC-logs, JFR, JMX, and the SA-agent all provide ways to inspect heap usage (including eden). These tools are actively maintained and should be preferred over jstat for this purpose.
22-05-2025

Could we get someone from the GC team to explain why the "some GC space counters for serial and parallel GC" are not actually needed and thus it is okay to get rid of them? EDIT: I see there is a bit more explanation in the CSR request, but the uselessness of these counters should be described more clearly. In particular the comment in the CSR that "the reported eden usage without sampling will always be 0" makes it sound like we are losing useful information. ??
08-05-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24872 Date: 2025-04-25 10:38:39 +0000
25-04-2025

Provisional changes: https://github.com/openjdk/jdk/compare/master...caspernorrbin:jdk:statsampler-removal
23-04-2025

There's no code that dynamically create a sampled counter. And no sampled counters apart from the handful that I remove in the PoC patch. You might be thinking of how jstat periodically samples PerfData counters as exposed via JMX/jvmstat - functionality which should be unaffected by this removal/cleanup.
26-03-2020

Doesn't jstat allow you to dynamically enable the counters you want sampled ??
26-03-2020

PoC: http://cr.openjdk.java.net/~redestad/scratch/perf_sample.00/
26-03-2020