On Fri, 31 Jul 2026 08:50:36 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). 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. ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32142#issuecomment-5162310694
