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

sspitsyn · 2025-11-08T00:15:24Z

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)

Reviewers

Chris Plummer (@plummercj - Reviewer)
Leonid Mesnik (@lmesnik - Reviewer)

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

…tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

bridgekeeper · 2025-11-08T00:16:56Z

👋 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 · 2025-11-08T00:17:10Z

@sspitsyn This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: cjplummer, lmesnik

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 23 new commits pushed to the master branch:

ad3dfaf: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)
cc05530: 8371732: [redo] Change java.time month/day field types to 'byte'
91b97a4: 8371922: Remove unused NonblockingQueue class
... and 20 more: https://git.openjdk.org/jdk/compare/6322aaba63b235cb6c73d23a932210af318404ec...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-11-08T00:17:55Z

@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 · 2025-11-08T00:27:20Z

Webrevs

sendaoYan · 2025-11-08T08:20:19Z

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp

@@ -40,9 +40,9 @@ static const jlong EXPECTED_TIMEOUT = 1;
 static const jlong EXPECTED_TIMEOUT_ACCURACY_NS = 300000;

 #if (defined(WIN32) || defined(_WIN32))
-static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock update interval
+static const jlong EXPECTED_ACCURACY = 32; // 16ms is longest clock update interval


Does the comment 16ms should be updated.

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

plummercj · 2025-11-12T18:22:05Z

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp

 static const jlong EXPECTED_ACCURACY = 16; // 16ms is longest clock update interval
 #else
-static const jlong EXPECTED_ACCURACY = 10; // high frequency clock updates expected
+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.

I think the real issue is that EXPECTED_ACCURACY is incorrectly named. It is being used as a max amount of elapsed time, not as an "accuracy" value. The comment on the WIN32 part just adds to the confusion. The "max elapsed time" has to be 16 ms because that is the clock is only accurate to 16ms, so even 1ms of elapsed times will show up as 16ms. The comment "16ms is longest clock update interval" should read "shortest", not "longest".

EXPECTED_TIMEOUT_ACCURACY_NS also seems to be misnamed.

sspitsyn · 2025-11-14T20:31:19Z

Thank you for review, Chris!

sspitsyn · 2025-11-14T23:05:18Z

Thank you for review, Leonid!

sspitsyn · 2025-11-15T01:49:24Z

/integrate

openjdk · 2025-11-15T01:50:49Z

Going to push as commit f971ee5.
Since your change was applied there have been 26 commits pushed to the master branch:

7c169c9: 8365426: [macos26] Graphics2D tests fail on new macOS 26
bc928c8: 5038439: Warning message for literal shift amounts outside the canonical domain
7aff8e1: 8371319: java.lang.reflect.Method#equals doesn't short-circuit with same instances
... and 23 more: https://git.openjdk.org/jdk/compare/6322aaba63b235cb6c73d23a932210af318404ec...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-11-15T01:50:59Z

@sspitsyn Pushed as commit f971ee5.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: …

1df4f7d

…tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)

openjdk bot added the serviceability serviceability-dev@openjdk.org label Nov 8, 2025

openjdk bot added the rfr Pull request is ready for review label Nov 8, 2025

sendaoYan reviewed Nov 8, 2025

View reviewed changes

review: restore original EXPECTED_ACCURACY for Windows

c53f9b4

plummercj reviewed Nov 12, 2025

View reviewed changes

plummercj approved these changes Nov 13, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Nov 13, 2025

Merge

e98facf

lmesnik approved these changes Nov 14, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Nov 15, 2025

openjdk bot closed this Nov 15, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 15, 2025

sspitsyn deleted the f3 branch November 15, 2025 01:52

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

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

Conversation

sspitsyn commented Nov 8, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Nov 8, 2025

Uh oh!

openjdk bot commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

sendaoYan Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn Nov 9, 2025

Choose a reason for hiding this comment

Uh oh!

plummercj Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dholmes-ora Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

plummercj Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn commented Nov 14, 2025

Uh oh!

sspitsyn commented Nov 14, 2025

Uh oh!

sspitsyn commented Nov 15, 2025

Uh oh!

openjdk bot commented Nov 15, 2025

Uh oh!

openjdk bot commented Nov 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

sspitsyn commented Nov 8, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Nov 8, 2025 •

edited

Loading

openjdk bot commented Nov 8, 2025 •

edited

Loading

mlbridge bot commented Nov 8, 2025 •

edited

Loading

sspitsyn Nov 12, 2025 •

edited

Loading