> 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 one additional commit since the last revision: stricter check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24186/files - new: https://git.openjdk.org/jdk/pull/24186/files/2cfd63ce..453faf4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=01-02 Stats: 25 lines in 3 files changed: 7 ins; 2 del; 16 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
