On Tue, 4 Aug 2026 03:33:30 GMT, Shiv Shah <[email protected]> wrote: >> 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
There is this warning after the description > [JDK-8382272](https://bugs.openjdk.org/browse/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.) Do you really want to integrate this to jdk 27? Would it better to target the CR to `28` or `tbd`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32142#issuecomment-5177530117
