On Tue, 25 Mar 2025 16:35:04 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> 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. Yes... My concern was that 0x7FFFFFFFFFFFFFFF if actually returned, must surely indicate a problem, and the test has been checking if a long is > Long.MAX_VALUE, which can't be useful. So reducing it even slightly at least give the check some meaning. I can reduce the value further... The test obviously avoids guessing what the value should be, to avoid it varying too much one day, and causing a failure. I've seen the test with -Xcomp, log ns value of 48,580,000,000 but there might be much slower runs out there. If I use Long.max_value / 10000000 it would have to be about 20 times slower to cause a failure. Long.max_value / 1000000 = 9,223,372,036,854 Long.max_value / 10000000 = 922,337,203,685 Xcomp example 48,580,000,000 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012976566
