RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000) [v2]
David Holmes
dholmes at openjdk.org
Tue Nov 18 04:16:23 UTC 2025
On Mon, 17 Nov 2025 22:48:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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
More information about the serviceability-dev
mailing list