> 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(<name>) instead of getThreadIds(<class>) - 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 <id>" 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
> 
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

Shiv Shah has updated the pull request incrementally with one additional commit 
since the last revision:

  Explain per-test why a platform thread is used

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/32142/files
  - new: https://git.openjdk.org/jdk/pull/32142/files/504a8822..1355985b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=32142&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=32142&range=00-01

  Stats: 10 lines in 4 files changed: 4 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/32142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/32142/head:pull/32142

PR: https://git.openjdk.org/jdk/pull/32142

Reply via email to