On Tue, 4 Aug 2026 20:58:45 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? > > 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. I'm not sure what you are asking w.r.t. threads002. The changes below look fine. It was adding -trackallthreads that I think is problematic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3716172263
