RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency

[Kevin Walls]

On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent.
> Tests should retry some small number of times, rerunning the jstat tool to recapture data.

jstat reads PerfData counters, at random times (as designed), 
and tests assert that they are always consistent.
But PerfData counters are written individually and may not always be consistent.

e.g.

296 void G1MonitoringSupport::update_sizes() {
...
303     _to_space_counters->update_capacity(_survivor_space_committed);
304     _to_space_counters->update_used(_survivor_space_used);

If a space shrinks, we write a new capacity which might be lower than the previous-and-still-visible used value (for a very small time).
There has to be a small window where the assertions do not hold, and we seem to hit these occasionally over a period of years, e.g.

java.lang.RuntimeException: S1U > S1C (utilization > capacity)
at utils.JstatResults.assertThat(JstatResults.java:172)
at utils.JstatGcResults.assertConsistency(JstatGcResults.java:89)
at GcTest01.main(GcTest01.java:52)


The other known failure is:

java.lang.RuntimeException: GCT != (YGCT + CGCT + FGCT) (GCT = 0.051, YGCT = 0.008, CGCT = 0.026, FGCT = 0.0, (YCGT + CGCT + FGCT) = 0.034)
at utils.JstatResults.assertThat(JstatResults.java:172)
at utils.JstatGcResults.assertConsistency(JstatGcResults.java:123)
at GcTest01.main(GcTest01.java:52)

...where again there must be small windows for a problem when stats are updated.

The assertion of consistency should retry some limited number of times on inconsistent data.
If jstat data fetching is truly broken, or the data is truly incorrect, the test will hit the small retry limit and fail.

serviceability/tmtools/jstat/GcTest01.java 
and 
serviceability/tmtools/jstat/GcTest02.java are known to fail occasionally.

The known failures have commonly been with -Xcomp which can mean a slow test, but this does not reproduce on demand.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26094#issuecomment-3027592580