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.
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
8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() #3478
Conversation
…eadInfo.getLockOwnerName()
/label add hotspot-runtime |
|
@dcubed-ojdk |
@dcubed-ojdk |
Webrevs
|
Ping! Any takers for the new test review? |
Tap, tap, tap... is this thing working? :-) |
When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. |
It is not really useful to compare with the counter based M&M tests I am reworking the remaining existing counter based Thread-SMR tests with |
HI Dan,
Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.
Cheers,
David
* @summary The test checks that ThreadInfo.getLockOwnerName() returns a | ||
* non-null string for a blocked thread and then makes repeated calls | ||
* to getThreadInfo() and ThreadInfo.getLockOwnerName() until the thread | ||
* has exited. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra space before has.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
* has exited. | ||
* @requires vm.jvmti | ||
* @library /test/lib | ||
* @compile getLockOwnerName.java |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need a @compile statement for the current test file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted.
} | ||
} | ||
|
||
System.exit(run(timeMax, System.out) + exit_delta); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jtreg tests don't use System.exit!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... that's generally true, but this is a test that must be run as
"othervm" so this style of exit with the "+ exit_delta" logic has been
used for these kinds of stress tests. I think this style came from the
VMTestbase tests and I've used it with other stress tests.
|
||
while (testState != TS_BLOCKER_RUNNING) { | ||
try { | ||
barrierLaunch.wait(0); // wait until it is running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: we use wait() rather than wait(0)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed it in 5 places.
@dholmes-ora - Thanks for the review. Sorry for the delay in responding.
I've been working on other issues. Please see my embedded replies.
* @summary The test checks that ThreadInfo.getLockOwnerName() returns a | ||
* non-null string for a blocked thread and then makes repeated calls | ||
* to getThreadInfo() and ThreadInfo.getLockOwnerName() until the thread | ||
* has exited. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
* has exited. | ||
* @requires vm.jvmti | ||
* @library /test/lib | ||
* @compile getLockOwnerName.java |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted.
} | ||
} | ||
|
||
System.exit(run(timeMax, System.out) + exit_delta); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... that's generally true, but this is a test that must be run as
"othervm" so this style of exit with the "+ exit_delta" logic has been
used for these kinds of stress tests. I think this style came from the
VMTestbase tests and I've used it with other stress tests.
|
||
while (testState != TS_BLOCKER_RUNNING) { | ||
try { | ||
barrierLaunch.wait(0); // wait until it is running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed it in 5 places.
@dholmes-ora - Sorry I missed this comment:
This test stresses getThreadInfo() and ThreadInfo.getLockOwnerName() as a |
@dholmes-ora also sent the comment in email but it didn't seem to
I agree. In particular this legacy style approach with exit_delta == 95 is |
Hi Dan,
Seems fine. Thanks for the updates.
The proof of a test is in its execution :)
David
@dcubed-ojdk This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 198 new commits pushed to the
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.
|
@dholmes-ora - Thanks for the re-review. My Mach5 Tier[1-7] testing for an @plummercj - Are you still planning to review this new test? |
Yes |
Overall it looks good. Some minor suggestions, most of which can be ignored if you wish.
Is there a reason these tests were not placed under test/jdk/java/lang/management
?
// <join returns> | ||
// | ||
|
||
public class getLockOwnerName { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like I did that because the API is called:
ThreadInfo.getLockOwnerName()
Will fix the filenames and the classname.
System.err.println(" -p ::= print debug info"); | ||
System.err.println(" time_max ::= max looping time in seconds"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
::=
doesn't seem to be a convention we use in help output other than in the other recent tests you've added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a grammar notational style from my compiler theory days.
I've used '::=' and ':=' for years. What would you like it changed to?
Or can I just leave it and try to use '-' in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The convention for java tools seems to be to just use tabs to align the start of the argument descriptions:
-p print debug info
time_max max looping time in seconds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
getLockOwnerName.logDebug("thread running"); | ||
|
||
// | ||
// Launch the blocker thread: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
// - holds threadLock until we tell it let go | ||
// - releases threadLock | ||
// | ||
if (getName().equals("blocker")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new test is a variation of a 20 year old test that I recently ported to JVM/TI
and integrated. 20 years ago, it was much simpler to write the test this way.
I could create a separate Thread subclass for each "role", but I'd rather not
do that since it will no longer be easy to compare this test to its siblings.
As for lambdas, I know absolutely zero about writing lambda code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them:
// create thread with specified method as the "run" method
Thread t = new Thread(this::testMethod);
t.start();
// create thread with the specified code block as the "run" method
Thread t1 = new Thread(() -> {
synchronized (lock1) {
System.out.println("Thread in sync section 1: "
+ Thread.currentThread().getName());
test1();
}
// create a static Runnable object using a lambda and use it as the Runnable for a new Thread
static final Runnable CONSUMER = () -> {
remove(QUEUE);
};
...
Thread t = new Thread(CONSUMER);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll pass on the lambdas.
Mailing list message from David Holmes on hotspot-runtime-dev: On 1/05/2021 6:57 am, Daniel D.Daugherty wrote:
Hmmm... this is a legacy style/approach that is not necessary any more. YMMV. Cheers, |
1 similar comment
Mailing list message from David Holmes on hotspot-runtime-dev: On 1/05/2021 6:57 am, Daniel D.Daugherty wrote:
Hmmm... this is a legacy style/approach that is not necessary any more. YMMV. Cheers, |
Thanks for the review. I made some of the changes, but not all of them.
These tests are for stressing particular HotSpot implementation pieces that are used
And we're stressing getLockOwnerName() because we had a non-reproducible So I think this stress test (along with others that I've written in this family) belong |
@plummercj - please mark this as 'Reviewed' if this latest version is acceptable. Thanks. |
@dholmes-ora and @plummercj - Thanks for the reviews. /integrate |
@dcubed-ojdk Since your change was applied there have been 200 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 8c71144. |
The synopsis pretty much says it all. There's a more detailed history in the RFE itself.
Currently running the new test thru Mach5 Tier[1-7].
I've run the test thru several 12 hour runs on my MBP13 and
on my Linux-X64 server.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478
$ git checkout pull/3478
Update a local copy of the PR:
$ git checkout pull/3478
$ git pull https://git.openjdk.java.net/jdk pull/3478/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3478
View PR using the GUI difftool:
$ git pr show -t 3478
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3478.diff