8382272: Update nsk/jdb tests to use ThreadWrapper

[shivshah-oracle]

Converts the tested threads in nsk/jdb to jdk.test.lib.thread.ThreadWrapper so they can run under JTREG_TEST_THREAD_FACTORY=Virtual. Per JDK-8381657, the conversion targets "spawned threads that make actual work in the tests".

12 debuggees converted. Because jdb output identifies threads by name, threads that stored their name in a field without setting it now call super(name), and the debuggers look threads up with getThreadIdsByName() instead of getThreadIds() - after conversion the running class is java.lang.Thread / VirtualThread, not the test's own class. next001a and step_up001a additionally gain a naming constructor: unnamed virtual threads have an empty name (platform threads get "Thread-N"), which made jdb's breakpoint prompt unrecognizable to the harness.

10 of these tests pass -jdb.option=-trackallthreads in their @run block (per-test, following the nsk/jdi -includevirtualthreads precedent): jdb only tracks a virtual thread once it sees an event on it, so tested threads were otherwise missing from "threads" output. thread002's switch check now greps each thread command's own reply (the name appears three times in the accumulated output), and interrupt001's tid pattern matches on thread name rather than class.

Four tests stay on platform threads, each with a comment giving the reason:

threadgroup002 / threadgroups002 - their threads take super(group, name); Thread.Builder.OfVirtual has no
ThreadGroup option, and thread-group placement is what these tests exercise
kill/kill002 - jdb's kill (JVMTI StopThread) rejects a virtual thread unmounted in Object.wait() with "Operation is not supported on the current frame"
suspend/suspend001 - after "suspend " of the virtual thread plus "cont", jdb stops responding (no prompt); happy to file a separate bug if this looks like a jdb/JDI issue worth tracking
trace001 and kill001 are unchanged - their threads already go through JDIThreadFactory, so they are virtual-capable

Testing: full nsk/jdb on linux-x64-OL-9 with the default factory and with JTREG_TEST_THREAD_FACTORY=Virtual - all pass in both; plus a five-platform run (linux-x64, linux-aarch64, macosx-x64, macosx-aarch64, windows-x64) in both modes

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

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-8382272: Update nsk/jdb tests to use ThreadWrapper (Sub-task - P4)(⚠️ The fixVersion in this issue is [27] but the fixVersion in .jcheck/conf is 28, a new backport will be created when this pr is integrated.)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 32142

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@shivshah-oracle 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.

[mlbridge]

Webrevs

• 00: Full (504a8822)

[dholmes-ora]

There are a number of comments about why a test can't use virtual threads, with a comment "see JDK-8382272". But there is no information in JDK-8382272 to see. ??

[shivshah-oracle]

There are a number of comments about why a test can't use virtual threads, with a comment "see JDK-8382272". But there is no information in JDK-8382272 to see. ??

Good catch. JDK-8382272 still only had the placeholder description. I’ve added a comment there with the specific reason each of the four tests remains on platform threads, so the references now provide useful context. I can also put the short reason directly in each test if you think that would be clearer