Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
+1 −1
Open

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

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
1df4f7d
8349192: Test jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: …
sspitsyn Nov 8, 2025
c53f9b4
review: restore original EXPECTED_ACCURACY for Windows
sspitsyn Nov 9, 2025
e98facf
Merge
sspitsyn Nov 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ 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
#else
static const jlong EXPECTED_ACCURACY = 10; // high frequency clock updates expected
static const jlong EXPECTED_ACCURACY = 32; // high frequency clock updates expected
Copy link
Contributor

@plummercj plummercj Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@sspitsyn sspitsyn Nov 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

#endif

/* scaffold objects */
Expand Down