On Wed, 12 Nov 2025 18:22:05 GMT, Chris Plummer <[email protected]> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: restore original EXPECTED_ACCURACY for Windows
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp
> line 45:
>
>> 43: static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock
>> update interval
>> 44: #else
>> 45: static const jlong EXPECTED_ACCURACY = 32; // high frequency clock
>> updates expected
>
> The comments are somewhat misleading now. We choose 16 on WIN32 because that
> is the smallest interval allowed. We expect better clock refinement on other
> platforms and therefore better accuracy. Thus 10ms was chosen. Now we have
> one test case that was just over 16ms. Is there a reason to believe that
> couldn't happen with WIN32 also. If not, then the comments should reflect
> that.
I feel that all these checks are just a source of this test instability. :)
I'm not sure I fully understand why those are needed and what was the original
design. It is always possible to have some delays in waiting time, so the
original assumptions about expected accuracy are not fully correct as they are
a little bit overly strong.
>From this point of view, I do not see why the comments are confusing. The
>`EXPECTED_ACCURACY` values are just based on the high frequency clock updates
>interval but should not be equal to it.
Would you like me to change the comments to something like below ? :
`high frequency clock updates expected`
=>
`expected accuracy is based on high frequency clock updates`
I do not want to change the Windows part until any failure is observed but
can update the comment for consistency.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2520042629
