jmx-dev RFR: 8351359: OperatingSystemMXBean: values from getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)

[Kevin Walls]

On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> OperatingSystemImpl.c on Windows is limited by its use of clock(), which hits its limit with longer process uptimes.
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/clock?view=msvc-170
> "maximum clock function return value of 2147483.647 seconds, or about 24.8 days"
> 
> The linked alternative, time(), gives 64-bit time but only seconds.  In the example code for time(), there is use of _ftime() to retrieve milliseconds.
> 
> The example code also notes that _ftime is deprecated, so _ftime_s is used here.

Thanks Alex -
Yes, good point, and luckily it isn't that bad.  GetTickCount64 does look like a good choice, I'm updating this.  _ftime_s() works fine in practice but GetTickCount64 seems like a better choice.

Testing existing behaviour using clock(), using _ftime_s(), and using GetTickCount64(): setting the clock back breaks one sample, we return -1, and keep returning that for one sampling "window", then it's fixed.  That's a reasonable disruption when the system time is changed, and is how it's always been.

With ftime_s() I suppose it's the negative time difference being treated as an unsigned uint64_t, it's a very big number, so the behaviour is the same as other methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/25062#issuecomment-2858199438