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