> 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).
Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - whitespace - whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24186/files - new: https://git.openjdk.org/jdk/pull/24186/files/21ebab5b..2cfd63ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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
