RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing

Andrei Pangin apangin at openjdk.org
Thu Sep 18 02:09:35 UTC 2025


On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 99:

> 97:     }
> 98: 
> 99:     public static void main(String[] args) throws Exception {

A brief high-level explanation of what the test does would be useful.
>From what I understood, the test starts CPU time sampling with a short interval (1ms), temporarily disables processing of native samples to cause queue overflow, then enables it back to report lost samples. Repeats the cycle 5 times and verifies that the queue has grown by the time of the last iteration, thereby decreasing the amount of losses.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 103:

> 101:             // setup recording
> 102:             AtomicLong burstThreadId = new AtomicLong();
> 103:             final long startTimeMillis = System.currentTimeMillis();

Do not use `System.currentTimeMillis()` for time intervals: 1) it suffers from rounding errors due to low resolution; 2) it is not guaranteed to be monotonic. Use `System.nanoTime()` or `Instant.now()` instead.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 119:

> 117:             rs.startAsync();
> 118:             // this thread runs all along
> 119:             Thread burstThread = new Thread(() -> WHITE_BOX.busyWaitCPUTime(8000));

Instead of having a magic constant, is it possible to run `busyWaitCPUTime` continuously until explicitly stopped?

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154:

> 152:         ThreadMXBean bean = ManagementFactory.getThreadMXBean();
> 153:         long start = bean.getCurrentThreadCpuTime();
> 154:         while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) {

Isn't this method supposed to check CPU time of the passed `thread` rather than current thread?

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 165:

> 163:         }
> 164:         // check that there are at least 3 time boxes
> 165:         Asserts.assertTrue(timeBoxedLosses.size() > 3);

Not sure what this assert means. From what I see, the size of `timeBoxedLosses` should be exactly equal to the number of main loop iterations (5).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357301273
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357230947
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357285587
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357280422
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357246767


More information about the hotspot-jfr-dev mailing list