On Mon, 10 Nov 2025 03:15:06 GMT, Chris Plummer <[email protected]> wrote:
> This is first of what will probably be 3 PRs to improve virtual thread > ThreadNode handling in the debug agent, with a goal of improving performance > and reducing footprint. > > This PR focuses on purging virtual thread ThreadNodes in two places: > > 1. Freeing the ThreadNode after handling a THREAD_START event for a virtual > thread. > 2. Doing a "GC" of virtual thread ThreadNodes just before doing a "suspend > all" > > At some point in the future I want to attempt to free the ThreadNodes after > performing ThreadReference related commands, which will result in the > creation of a ThreadNode if not already created. Another area is in > handleReportEventCompositeCommand() when the thread is not null and we are > using the SUSPEND_NONE policy. This will get more ThreadNodes freed > immediately after handling an event. > > Part of the challenge with this PR is that there are many places in the debug > agent that expect a ThreadNode to already have been created for the virtual > thread, but now it is common that they have not. The main way this has been > addressed is by having findRunningThread() create the ThreadNode if it does > not already exist. > > At some point in the future I will probably add logic to only "GC" > ThreadNodes after the number reaches some threshold, but right now I want to > free them very aggressively so we'll catch any bugs where there debug agent > expects a ThreadNode to exist, but possibly now it might not. > > Tested by running all tier2, tier5, and tier6 CI svc tests. This pull request has now been integrated. Changeset: 2b5cd14e Author: Chris Plummer <[email protected]> URL: https://git.openjdk.org/jdk/commit/2b5cd14ea5c571e0d55df8293e49b9a0db521a46 Stats: 244 lines in 1 file changed: 187 ins; 39 del; 18 mod 8282441: [LOOM] The debug agent should attempt to free vthread ThreadNodes Reviewed-by: amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28211
