8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() #3478

dcubed-ojdk · 2021-04-14T00:08:52Z

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

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()

Reviewers

David Holmes (@dholmes-ora - Reviewer) ⚠️ Review applies to 771dafe
Chris Plummer (@plummercj - Reviewer)

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

…eadInfo.getLockOwnerName()

dcubed-ojdk · 2021-04-14T00:09:08Z

/label add hotspot-runtime
/label add serviceability

bridgekeeper · 2021-04-14T00:18:37Z

👋 Welcome back dcubed! 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 · 2021-04-14T00:20:17Z

@dcubed-ojdk
The hotspot-runtime label was successfully added.

openjdk · 2021-04-14T00:21:35Z

@dcubed-ojdk
The serviceability label was successfully added.

mlbridge · 2021-04-14T00:25:23Z

Webrevs

dcubed-ojdk · 2021-04-19T20:35:37Z

Ping! Any takers for the new test review?

dcubed-ojdk · 2021-04-27T19:33:26Z

Tap, tap, tap... is this thing working? :-)

plummercj · 2021-04-27T23:21:51Z

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.

dcubed-ojdk · 2021-04-27T23:52:41Z

It is not really useful to compare with the counter based M&M tests
because this test is exercising/stressing a different API. It could be
useful to compare this test to runtime/Thread/SuspendAtExit.java
which is a test that was also updated to be time based instead of
counter based.

I am reworking the remaining existing counter based Thread-SMR tests with
a different bug ID (https://bugs.openjdk.java.net/browse/JDK-8266130),
but that is a work-in-progress.

dholmes-ora

HI Dan,

Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.

Cheers,
David

dholmes-ora · 2021-04-28T13:03:15Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+ * @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.


Extra space before has.

dholmes-ora · 2021-04-28T13:03:15Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+ *    has exited.
+ * @requires vm.jvmti
+ * @library /test/lib
+ * @compile getLockOwnerName.java


You don't need a @compile statement for the current test file

dholmes-ora · 2021-04-28T13:03:15Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+            }
+        }
+
+        System.exit(run(timeMax, System.out) + exit_delta);


jtreg tests don't use System.exit!

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.

dholmes-ora · 2021-04-28T13:03:15Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+
+                while (testState != TS_BLOCKER_RUNNING) {
+                    try {
+                        barrierLaunch.wait(0);  // wait until it is running


Nit: we use wait() rather than wait(0)

I fixed it in 5 places.

dcubed-ojdk

@dholmes-ora - Thanks for the review. Sorry for the delay in responding.
I've been working on other issues. Please see my embedded replies.

dcubed-ojdk · 2021-04-30T20:55:12Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+ * @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.


dcubed-ojdk · 2021-04-30T20:55:12Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+ *    has exited.
+ * @requires vm.jvmti
+ * @library /test/lib
+ * @compile getLockOwnerName.java


dcubed-ojdk · 2021-04-30T20:55:12Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+            }
+        }
+
+        System.exit(run(timeMax, System.out) + exit_delta);


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.

dcubed-ojdk · 2021-04-30T20:55:12Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+
+                while (testState != TS_BLOCKER_RUNNING) {
+                    try {
+                        barrierLaunch.wait(0);  // wait until it is running


I fixed it in 5 places.

dcubed-ojdk · 2021-05-11T23:22:20Z

@dholmes-ora - Sorry I missed this comment:

Some minor comments, but to be frank I have no idea what this test is actually doing - sorry.

This test stresses getThreadInfo() and ThreadInfo.getLockOwnerName() as a
JavaThread is exiting. Similar to other stress tests that I wrote for M&M in the
Thread-SMR project, but this one is targeting getting the lock owner name as
the lock owner thread is exiting.

dcubed-ojdk · 2021-05-11T23:26:02Z

@dholmes-ora also sent the comment in email but it didn't seem to
show up in this PR:

Hmmm... this is a legacy style/approach that is not necessary any more.
If the test fails it should throw an exception from the main thread and
that will produce a non-zero exit value. I think seeing this legacy style in
new tests will just confuse people.

I agree. In particular this legacy style approach with exit_delta == 95 is
for VMTestbase tests and this new test is not part of the VMTestbase
test suite. I'm fixing this.

dholmes-ora

Hi Dan,

Seems fine. Thanks for the updates.

The proof of a test is in its execution :)

David

openjdk · 2021-05-13T08:13:53Z

@dcubed-ojdk 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:

8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()

Reviewed-by: dholmes, cjplummer

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 master branch:

7ab6dc8: 6676643: Improve current C_GetAttributeValue native implementation
28f1c7a: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems
be0a655: 8254598: StringDedupTable should use OopStorage
360928d: 8260046: Assert left >= right in pointer_delta() methods
5eda812: 8267180: Typo in copyright header for HashesTest
e90388b: 8266461: tools/jmod/hashes/HashesTest.java fails: static @test methods
599d07c: 8263006: Add optimization for Max()Node and Min()Node
16ca370: 8265694: Investigate test StressHiddenClasses.java
af4cd04: 8266291: (jrtfs) Calling Files.exists may break the JRT filesystem
ebcf399: 8266622: Optimize Class.descriptorString() and Class.getCanonicalName0()
... and 188 more: https://git.openjdk.java.net/jdk/compare/50fa1623adca74f79413fd127d4338901da4678d...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.

dcubed-ojdk · 2021-05-13T15:37:43Z

@dholmes-ora - Thanks for the re-review. My Mach5 Tier[1-7] testing for an
earlier version of the test is documented in the bug report.

@plummercj - Are you still planning to review this new test?

plummercj · 2021-05-13T18:01:27Z

@plummercj - Are you still planning to review this new test?

Yes

plummercj

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?

plummercj · 2021-05-14T04:45:36Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+// <join returns>
+//
+
+public class getLockOwnerName {


Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name.

Looks like I did that because the API is called:
ThreadInfo.getLockOwnerName()
Will fix the filenames and the classname.

plummercj · 2021-05-14T04:45:36Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+        System.err.println("    -p       ::= print debug info");
+        System.err.println("    time_max ::= max looping time in seconds");


::= doesn't seem to be a convention we use in help output other than in the other recent tests you've added.

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?

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

plummercj · 2021-05-14T04:45:36Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+        getLockOwnerName.logDebug("thread running");
+
+        //
+        // Launch the blocker thread:


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.

plummercj · 2021-05-14T04:45:36Z

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java

+        // - holds threadLock until we tell it let go
+        // - releases threadLock
+        //
+        if (getName().equals("blocker")) {


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.

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.

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);

I'll pass on the lambdas.

mlbridge · 2021-05-14T18:29:24Z

Mailing list message from David Holmes on hotspot-runtime-dev:

On 1/05/2021 6:57 am, Daniel D.Daugherty wrote:

On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137:

135: }
136:
137: System.exit(run(timeMax, System.out) + exit_delta);

jtreg tests don't use System.exit!

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.

Hmmm... this is a legacy style/approach that is not necessary any more.
If the test fails it should throw an exception from the main thread and
that will produce a non-zero exit value. I think seeing this legacy
style in new tests will just confuse people.

YMMV.

Cheers,
David

mlbridge · 2021-05-14T18:29:31Z

Mailing list message from David Holmes on hotspot-runtime-dev:

On 1/05/2021 6:57 am, Daniel D.Daugherty wrote:

On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137:

135: }
136:
137: System.exit(run(timeMax, System.out) + exit_delta);

jtreg tests don't use System.exit!

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.

Hmmm... this is a legacy style/approach that is not necessary any more.
If the test fails it should throw an exception from the main thread and
that will produce a non-zero exit value. I think seeing this legacy
style in new tests will just confuse people.

YMMV.

Cheers,
David

dcubed-ojdk · 2021-05-14T22:11:52Z

Overall it looks good. Some minor suggestions, most of which can be ignored if you wish.

Thanks for the review. I made some of the changes, but not all of them.

Is there a reason these tests were not placed under test/jdk/java/lang/management?

These tests are for stressing particular HotSpot implementation pieces that are used
by the M&M APIs. In particular, they are stressing the use of ThreadsListHandles
in both the safepoint and non-safepoint code paths traveled by getThreadInfo():

                // maxDepth == 0 requires no safepoint so alternate.
                int maxDepth = ((count % 1) == 1) ? Integer.MAX_VALUE : 0;
                info = mbean.getThreadInfo(id, maxDepth);
                if (info == null) {
                    // the contender has exited
                    break;
                }
                name = info.getLockOwnerName();

And we're stressing getLockOwnerName() because we had a non-reproducible
bug that crashed in that particular function after the getThreadInfo() call.

So I think this stress test (along with others that I've written in this family) belong
in the test/hotspot collection of tests.

dcubed-ojdk · 2021-05-14T23:53:42Z

@plummercj - please mark this as 'Reviewed' if this latest version is acceptable. Thanks.

dcubed-ojdk · 2021-05-15T13:12:55Z

@dholmes-ora and @plummercj - Thanks for the reviews.

/integrate

openjdk · 2021-05-15T13:15:13Z

@dcubed-ojdk Since your change was applied there have been 200 commits pushed to the master branch:

10cafd2: 8267153: Problemlist jdk/jfr/event/gc/collection/TestG1ParallelPhases.java to remove the noise from CI
f3fb5a4: 8266942: gtest/GTestWrapper.java os.iso8601_time_vm failed
7ab6dc8: 6676643: Improve current C_GetAttributeValue native implementation
28f1c7a: 8249395: (macos) jpackage tests timeout on MacPro5_1 systems
be0a655: 8254598: StringDedupTable should use OopStorage
360928d: 8260046: Assert left >= right in pointer_delta() methods
5eda812: 8267180: Typo in copyright header for HashesTest
e90388b: 8266461: tools/jmod/hashes/HashesTest.java fails: static @test methods
599d07c: 8263006: Add optimization for Max()Node and Min()Node
16ca370: 8265694: Investigate test StressHiddenClasses.java
... and 190 more: https://git.openjdk.java.net/jdk/compare/50fa1623adca74f79413fd127d4338901da4678d...master

Your commit was automatically rebased without conflicts.

Pushed as commit 8c71144.

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

8265153: add time based test for ThreadMXBean.getThreadInfo() and Thr…

f6fbf71

…eadInfo.getLockOwnerName()

dcubed-ojdk marked this pull request as ready for review Apr 14, 2021

openjdk bot added rfr hotspot-runtime labels Apr 14, 2021

openjdk bot added the serviceability label Apr 14, 2021

dholmes-ora reviewed Apr 28, 2021

View changes

dcubed-ojdk reviewed Apr 30, 2021

View changes

dcubed-ojdk added 3 commits Apr 30, 2021

dholmes CR changes.

682a7c9

Merge branch 'master' into JDK-8265153

3b4004d

Remove unnecessary "@library /test/lib".

bac63a7

Drop exit_delta and the VMTestbase style of exiting on test failure.

771dafe

dholmes-ora approved these changes May 13, 2021

View changes

openjdk bot added the ready label May 13, 2021

plummercj reviewed May 14, 2021

View changes

dcubed-ojdk added 2 commits May 14, 2021

plummercj CR changes.

6a8e5e3

plummercj CR - drop '::=' from the usage() output.

185ee0f

plummercj approved these changes May 15, 2021

View changes

openjdk bot closed this May 15, 2021

openjdk bot added integrated and removed ready rfr labels May 15, 2021

dcubed-ojdk deleted the JDK-8265153 branch May 17, 2021

		System.err.println(" -p ::= print debug info");
		System.err.println(" time_max ::= max looping time in seconds");

8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() #3478

8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() #3478

Conversation

dcubed-ojdk commented Apr 14, 2021 • edited by openjdk[bot] bot

Progress

Issue

Reviewers

Reviewing

dcubed-ojdk commented Apr 14, 2021

bridgekeeper bot commented Apr 14, 2021

openjdk bot commented Apr 14, 2021

openjdk bot commented Apr 14, 2021

mlbridge bot commented Apr 14, 2021 • edited

Webrevs

dcubed-ojdk commented Apr 19, 2021

dcubed-ojdk commented Apr 27, 2021

plummercj commented Apr 27, 2021

dcubed-ojdk commented Apr 27, 2021

dholmes-ora left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dcubed-ojdk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dcubed-ojdk commented May 11, 2021

dcubed-ojdk commented May 11, 2021

dholmes-ora left a comment

openjdk bot commented May 13, 2021 • edited

dcubed-ojdk commented May 13, 2021

plummercj commented May 13, 2021

plummercj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mlbridge bot commented May 14, 2021

mlbridge bot commented May 14, 2021

dcubed-ojdk commented May 14, 2021

dcubed-ojdk commented May 14, 2021

dcubed-ojdk commented May 15, 2021

openjdk bot commented May 15, 2021

dcubed-ojdk commented Apr 14, 2021 •

edited by openjdk[bot] bot

mlbridge bot commented Apr 14, 2021 •

edited

openjdk bot commented May 13, 2021 •

edited