RFR: 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000) [v2]

Serguei Spitsyn sspitsyn at openjdk.org
Wed Nov 12 22:49:06 UTC 2025


On Wed, 12 Nov 2025 18:22:05 GMT, Chris Plummer <cjplummer at openjdk.org> 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


More information about the serviceability-dev mailing list