8356023: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 2

[plummercj]

A followup to JDK-8355773. Convert a bunch more tests to fetch the ThreadReference from a static field in the debuggee. JDK-8355773 focused on the easier tests that already had a static field, and the name of the field was the same as the thread name. This batch takes care of a bunch of harder to convert tests where in many cases static field has to be added and usually does not have the same name as the thread name.

Note there was a lot of template copy-n-paste code that I deleted because it was never used. For example, most tests were not using the listIterator variable. There were also many deletions of calls to vm.allThreads(). Some were because the need to iterate over the threads went away, but most were because the result was never used.

There are many places where the original code iterated over all the threads looking for a particular thread rather than calling on of the existing threadByName() APIs, and you'll see this being replaced by calls to the new threadByFieldNameOrThrow() API. One thing to keep in mind is that the old code tried to continue running the test if it failed to find the thread. This would lead to a timeout. threadByFieldNameOrThrow() will throw an exception which forces the test to quickly exit.

I added a 2nd threadByFieldNameOrThrow() API. The original one just took a threadFieldName argument, assuming that the name of the static field and the name of the thread were the same. The new one adds a threadName argument, allowing for the two to be different. The threadName is used just to double check that the Thread fetched from the static field has the expected name. It is not used as part of the lookup.

Tested with CI tier5, which is where all the nsk/jdi testing is done. Also ran locally on linux-x64.

---

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-8356023: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 2 (Enhancement - P4)

Reviewers

• Alex Menkov (@alexmenkov - Reviewer)
• Serguei Spitsyn (@sspitsyn - Reviewer)
• Leonid Mesnik (@lmesnik - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24979

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8356023: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 2

Reviewed-by: amenkov, sspitsyn, lmesnik

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

• 2ea629f: 8353440: Disable FTP fallback for non-local file URLs by default
• 57297e6: 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197
• 900b3ff: 8351359: OperatingSystemMXBean: values from getCpuLoad and getProcessCpuLoad are stale after 24.8 days (Windows)
• ... and 125 more: https://git.openjdk.org/jdk/compare/e2ae50d877b13b121912e2496af4b5209b315a05...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.

[openjdk]

@plummercj The following label will be automatically applied to this pull request:

• serviceability

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

[plummercj]

Note, mainThread is not reference later in the test so is no longer being looked up (and I deleted the field above). There are a couple more test below where the same is done.

[mlbridge]

Webrevs

• 01: Full - Incremental (3f7c4a03)
• 00: Full (c43ff38c)

[alexmenkov]

Looks good in general, good to see all this stuff dropped.
One file has only copyright line change.

[alexmenkov]

There are no changes in the file

[sspitsyn]

This is also a nice unification, simplification and cleanup. Looks good.

[plummercj]

Thank you for the reviews Alex, Serguei, and Leonid.

/integrate

[openjdk]

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

• 24d84cf: 8354091: Update RELEASE_25 description for Flexible Constructor Bodies
• 1e8927d: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong
• 7f3191a: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300
• ... and 130 more: https://git.openjdk.org/jdk/compare/e2ae50d877b13b121912e2496af4b5209b315a05...master

Your commit was automatically rebased without conflicts.

[openjdk]

@plummercj Pushed as commit 9273094.

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