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

Closed
wants to merge 3 commits into from
Closed

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

Changes from 1 commit
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
4 changes: 2 additions & 2 deletions 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 @@ -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
Copy link
Member

@sendaoYan sendaoYan Nov 8, 2025

Choose a reason for hiding this comment

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

Does the comment 16ms should be updated.

Copy link
Contributor Author

@sspitsyn sspitsyn Nov 9, 2025

Choose a reason for hiding this comment

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

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

#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.

Copy link
Member

@dholmes-ora dholmes-ora Nov 17, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@plummercj plummercj Nov 17, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

@sspitsyn sspitsyn Nov 17, 2025

Choose a reason for hiding this comment

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

Thank you, Chris. My intention was to fix this intermittent failure and achieve better stability. My preference would be to get rid of these troublesome and useless checks instead of fixing confusing constant names and comments.

Copy link
Member

@dholmes-ora dholmes-ora Nov 18, 2025

Choose a reason for hiding this comment

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

The comment "16ms is longest clock update interval" should read "shortest", not "longest".

No it is the longest interval between clock updates (actually 15.259) based on the old PIT timer (1/65536). Modern hardware will have 10ms or even 1ms.

The code expects to see at most one timer-tick of elapsed time, hence the name and the value.

#endif

/* scaffold objects */
Expand Down