On Tue, 4 Aug 2026 18:27:27 GMT, Chris Plummer <[email protected]> wrote:
> 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3715735270
