On Wed, 12 Nov 2025 22:45:05 GMT, Serguei Spitsyn <[email protected]> wrote:
>> 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. This is wrong. The "expected" accuracy is still 10ms or even 1ms, it is never 32ms. The test may need to wait longer but changing this value makes no sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2532387592
