On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> 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 test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line 60: > 58: // Careful with these values. > 59: private static final long MIN_TIME_FOR_PASS = 1; > 60: private static final long MAX_TIME_FOR_PASS = Long.MAX_VALUE / 1000; I think this is still 9,223,372 seconds. Seems it should be lower. It might be best to work in the opposite direction. Decide how many seconds and then multiply that by 1,000,000,000. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012500672
