jmx-dev RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently [v4]

[Kevin Walls]

On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls <kevinw at 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 max time

Thanks for all the reviews and comments.

The timing check in GetSystemCpuLoad.java is a little hacky.  That test has never claimed to try and test that the cpu time is "correct", but now it will at least test the time measured is not crazy.  If I got the definition of "crazy" wrong, will be back here...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2753660969