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.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 431:

> 429:         }
> 430: #endif
> 431: 

I moved this to earlier in the function because at one point I was using the 
thread name in some debug printfs, and the thread name was being setup too 
late. I decided to keep it here just in case I need to do that again in the 
future.

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1356:

> 1354:         } else {
> 1355:             *count = 0;
> 1356:         }

This change could use some explaining to help with the review. After this 
change the code is back to what it was before vthread support was added. This 
extra work was needed because sometimes the ThreadNode for the vthread did not 
already exist. Since now findRunningThread() will create the ThreadNode, there 
is no longer a need for this code to deal with it not existing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2508595620
PR Review Comment: https://git.openjdk.org/jdk/pull/28211#discussion_r2508599927

Reply via email to