8306446: java/lang/management/ThreadMXBean/Locks.java transient failures

[kevinjwalls]

This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.

There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.

The test has additional problems when started in a virtual thread. ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads. The test needs to avoid some checks if mainThread is virtual.

In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing. It's not one of the very narrow set of threads this test cares about.

Despite these exclusions, the test does some reasonable verification work when MainThread is virtual. This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.

There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure. Make the loop count the failures, and throw if there are any.

Also, while looking into this... The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.

The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
LockAThread blocked on Locks$ObjectB@4691fdfd
(ObjectB, not just Object).

---

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-8306446: java/lang/management/ThreadMXBean/Locks.java transient failures (Bug - P4)

Reviewers

• Chris Plummer (@plummercj - Reviewer) ⚠️ Review applies to 02ba2a31
• Serguei Spitsyn (@sspitsyn - Reviewer) ⚠️ Review applies to 02ba2a31

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14501/head:pull/14501
$ git checkout pull/14501

Update a local copy of the PR:
$ git checkout pull/14501
$ git pull https://git.openjdk.org/jdk.git pull/14501/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14501

View PR using the GUI difftool:
$ git pr show -t 14501

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14501.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back kevinw! 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]

@kevinjwalls The following labels will be automatically applied to this pull request:

• core-libs
• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[AlanBateman]

/label remove core-libs

[openjdk]

@AlanBateman
The core-libs label was successfully removed.

[mlbridge]

Webrevs

• 05: Full - Incremental (8107ee72)
• 04: Full - Incremental (2767ed08)
• 03: Full - Incremental (02ba2a31)
• 02: Full - Incremental (3e09f14e)
• 01: Full - Incremental (7bd08854)
• 00: Full (c2e2a5b6)

[dholmes-ora]

In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.

Can you elaborate on this please. I'm unclear how the test knows whether a thread may be holding any locks or not, but why is locking a VirtualThread instance a special case??

[AlanBateman]

Can you elaborate on this please. I'm unclear how the test knows whether a thread may be holding any locks or not, but why is locking a VirtualThread instance a special case??

Carriers are reported as waiting, the string representation of the object that they are waiting on is the identity string of the virtual thread that is mounted.

[kevinjwalls]

Thanks Alan, yes-
All the TEST really knows is the couple of threads it creates, and the lock objects it creates. When it says "assert no lock held", it means to assert that none of the locks that it created and cares about are held.

When MainThread is Virtual, as started by jtreg, the test asserts that no locks it cares about are held by MainThread. When there is an additional locked object (a VirtualThread), that surprises the test. Hence the filter on getLockName() in assertNoLock.

[bridgekeeper]

@kevinjwalls This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[sspitsyn]

This looks pretty good to me.
Is the test not failing anymore with your update?

[kevinjwalls]

This looks pretty good to me. Is the test not failing anymore with your update?

Thanks Serguei, yes it's running reliably, including with virtual threads, with this change (I just ran it, 50 times per platform, to re-check).

[openjdk]

@kevinjwalls 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:

8306446: java/lang/management/ThreadMXBean/Locks.java transient failures

Reviewed-by: cjplummer, sspitsyn

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 27 new commits pushed to the master branch:

• cad6114: 8304954: SegmentedCodeCache fails when using large pages
• ba645da: 8313082: Enable CreateCoredumpOnCrash for testing in makefiles
• c27c877: 8302017: Allocate BadPaddingException only if it will be thrown
• c55d29f: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code
• 0ca2bfd: 8311104: dangling-gsl warning in libwixhelper.cpp
• c05ba48: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX
• 169b6e3: 8313174: Create fewer predictable port clashes in management tests
• 8650026: 8310033: Clarify return value of Java Time compareTo methods
• 25058cd: 8312620: WSL Linux build crashes after JDK-8310233
• 8661b8e: 8312495: assert(0 <= i && i < _len) failed: illegal index after JDK-8287061 on big endian platforms
• ... and 17 more: https://git.openjdk.org/jdk/compare/e9daf4a0185b90762d2bdd38d86fe93b4822ea08...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.

[kevinjwalls]

Thanks for the reviews! I will add one small comment and integrate.

[kevinjwalls]

/integrate

[openjdk]

@kevinjwalls Your integration request cannot be fulfilled at this time, as the status check jcheck-openjdk/jdk-14501 did not complete successfully

[kevinjwalls]

/integrate

[openjdk]

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

• cad6114: 8304954: SegmentedCodeCache fails when using large pages
• ba645da: 8313082: Enable CreateCoredumpOnCrash for testing in makefiles
• c27c877: 8302017: Allocate BadPaddingException only if it will be thrown
• c55d29f: 8312626: Resolve multiple definition of 'start_timer' when statically linking JDK native libraries with user code
• 0ca2bfd: 8311104: dangling-gsl warning in libwixhelper.cpp
• c05ba48: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX
• 169b6e3: 8313174: Create fewer predictable port clashes in management tests
• 8650026: 8310033: Clarify return value of Java Time compareTo methods
• 25058cd: 8312620: WSL Linux build crashes after JDK-8310233
• 8661b8e: 8312495: assert(0 <= i && i < _len) failed: illegal index after JDK-8287061 on big endian platforms
• ... and 17 more: https://git.openjdk.org/jdk/compare/e9daf4a0185b90762d2bdd38d86fe93b4822ea08...master

Your commit was automatically rebased without conflicts.

[openjdk]

@kevinjwalls Pushed as commit 4ae5a3e.

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