On Tue, 4 Aug 2026 17:44:03 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:
>
> Resolve tested threads by exact name to avoid ordering assumption
test/hotspot/jtreg/vmTestbase/nsk/jdb/thread/thread002/thread002.java line 52:
> 50: * -transport.address=dynamic
> 51: * -jdb=${test.jdk}/bin/jdb
> 52: * -jdb.option=-trackallthreads
My main concern with these changes we've been moving away from using
-trackallthreads (which maps to the debug agent includevirtualthreads=y). It is
not something debuggers are expected to use, so our testing should really be
with it disabled. The only reason these options still exist is so we can more
easily support our tests running with vthread support. I've already done a lot
of work getting rid of the use of includevirtualthreads=y in many tests. Search
for "includevirtualthreads=y" in JBS and you'll find about 5 bugs addressing
this. The proper solution here would be to have getThreadIdsByName(name) fetch
the threads from a debuggee static and not rely on the jdb "threads" command.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3715160288
