These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods. This seems to be a Windows 2019 bug or peculiarity. Other Windows versions are not affected. GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1. They should permit -1 values, as long as subsequently a value in the valid range is read. The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip. While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs). ------------- Commit messages: - whitespace - problemlist - Merge remote-tracking branch 'upstream/master' into 8351002_OSMXBean_CPU_Tests - 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently Changes: https://git.openjdk.org/jdk/pull/24186/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351002 Stats: 59 lines in 4 files changed: 44 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24186.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24186/head:pull/24186 PR: https://git.openjdk.org/jdk/pull/24186
