On Tue, 4 Aug 2026 21:16:06 GMT, Chris Plummer <[email protected]> wrote:
>> 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. > > It's unclear to me why your changes to the test resulted in needing to pass > -trackallthreads. You switched from getThreadIds() to getThreadIdsByName(), > but both use the set of threads returned by the "threads" command, so I don't > see why that change would impact the need for -trackallthreads. Sorry for the confusion. My “does that match” question was only confirming that thread002 will continue to test both the threads and thread commands after the rework; only the discovery setup will change. The getThreadIds() to getThreadIdsByName() change did not introduce the need for -trackallthreads. That change only removed the thread-ordering assumption identified in Serguei’s comment; both methods still parse the threads output. The need arose from the ThreadWrapper conversion. Once the tested threads become virtual, they are not present in the default threads output before delivering a debugger event, whereas the platform threads were always present. Adding -trackallthreads was the broad workaround. I’ll replace it by having each tested thread pass through a rendezvous breakpoint first. After jdb learns about them, the existing exact-name lookup and thread <id> checks work with the default agent behavior. I’ll then remove all the newly added -trackallthreads options. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3716574393
