On Tue, 4 Aug 2026 19:55:12 GMT, Shiv Shah <[email protected]> wrote: >> 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. > >> 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. > > Thanks, Chris. Before reworking this, I tested a bare jdb session without > -trackallthreads to determine what is available with the default agent > behavior > > Reading Debuggee.staticField for a virtual thread only produces its > toString() representation and it does not expose an ID that the thread > command accepts. Supplying the object ID directly also fails while the > virtual thread is unknown to jdb, so I think the JDI static field approach > does not transfer directly to the current jdb command path > > Once the virtual thread delivers a breakpoint event, however, jdb learns > about it. After continuing from the breakpoint, the thread remains in the > threads listing with a usable ID, and thread <id> succeeds. I verified this > with three virtual threads passing through a single rendezvous breakpoint and > all three stayed discoverable and switchable afterwards (and notably arrived > out of creation order, so the lookups stay keyed by exact name) > > So Im planning to do is... have each tested virtual thread pass through a > rendezvous breakpoint before the lookup, then remove all the newly added > -trackallthreads options and reuse the existing name lookup and thread switch > checks with the default agent behavior. For thread002 the actual threads and > thread <id> command coverage is preserved; only the discovery setup changes. > Does that match the direction you had in mind?
Yes, jdb does learn about vthreads that arrive in events, and they should be returned by the "threads" command until they exit. I did something similar with some of the nsk/jdi tests, relying on events to learn about threads. BTW, there are still some nsk/jdi tests that rely on includevirtualthreads=y. They are listed in [JDK-8356823](https://bugs.openjdk.org/browse/JDK-8356823) if you are interested in fixing them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3716136273
