On Mon, 17 Nov 2025 22:48:26 GMT, Serguei Spitsyn <[email protected]> wrote:
>> I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is >> being used as a max amount of elapsed time, not as an "accuracy" value. The >> comment on the WIN32 part just adds to the confusion. The "max elapsed time" >> has to be 16 ms because that is the clock is only accurate to 16ms, so even >> 1ms of elapsed times will show up as 16ms. The comment "16ms is longest >> clock update interval" should read "shortest", not "longest". >> >> EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed. > > Thank you, Chris. My intention was to fix this intermittent failure and > achieve better stability. My preference would be to get rid of these > troublesome and useless checks instead of fixing confusing constant names and > comments. > The comment "16ms is longest clock update interval" should read "shortest", > not "longest". No it is the longest interval between clock updates (actually 15.259) based on the old PIT timer (1/65536). Modern hardware will have 10ms or even 1ms. The code expects to see at most one timer-tick of elapsed time, hence the name and the value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2536241336
