On Sun, 9 Nov 2025 10:30:45 GMT, Serguei Spitsyn <[email protected]> wrote:
>> This is fix is to increase the `EXPECTED_ACCURACY` value in the test: >> `hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001`. >> It is used check that the waiting time between `MonitorWait` and >> `MonitorWaited` event is not big. It seems that in some corner cases this >> time can be bigger than expected. >> >> Testing: >> - TBD: Verify the test with mach5 test runs > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28206#discussion_r2519348665
