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

[sspitsyn]

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

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000) (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28206/head:pull/28206
$ git checkout pull/28206

Update a local copy of the PR:
$ git checkout pull/28206
$ git pull https://git.openjdk.org/jdk.git pull/28206/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28206

View PR using the GUI difftool:
$ git pr show -t 28206

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28206.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back sspitsyn! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@sspitsyn The following label will be automatically applied to this pull request:

• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (c53f9b40)
• 00: Full (1df4f7d3)

[sendaoYan]

Does the comment 16ms should be updated.

[sspitsyn]

Thank you for the comment. I've decided to restore the original EXPECTED_ACCURACY on Windows.

[plummercj]

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.

[sspitsyn]

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.