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
test/hotspot/jtreg/vmTestbase/nsk/jdb/thread/thread002/thread002.java line 108:
> 106: for (int i = 0; i < threadIds.length; i++) {
> 107: count = new Paragrep(switchReplies[i]).find(THREAD_NAME +
> "#" + i);
> 108: if (count == 0) {
Q: I see a potential issue (Is it pre-existed?). It seems, this test has an
assumption that the GDB`getThreadIds()` and `getThreadIdsByName()` return
thread IDs in a correct order matching this: `MyThread#0`, `MyThread#1`, etc.
I'm not sure it is the case. Should we double check this? If the returned order
can be different then I'm thinking if we can add a comment with a warning about
this potential problem or just fix the issue.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3711511371
