On Tue, 6 May 2025 10:20:22 GMT, Kevin Walls <kev...@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
