RFR: 8282441: [LOOM] The debug agent should attempt to free vthread ThreadNodes [v2]

[Serguei Spitsyn]

On Tue, 18 Nov 2025 04:59:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1399:
>> 
>>> 1397:     if (node == NULL) {
>>> 1398:         node = findThread(&otherThreads, thread);
>>> 1399:     }
>> 
>> Q: Could you explain a little bit why this change is needed? Do we need an update of the comment above?
>
> You need to call findRunningThread() to get the ThreadNode created if there isn't already one. findThread() does not create the ThreadNode like findRunningThread() does, so after my changes to free up ThreadNodes, findThread() was returning NULL, which causes a lot of problems here.
> 
> You then need to add the findThread(&otherThreads, thread) call because this is normally done by findThread() but is purposefully not done by findRunningThread(). otherThreads hold threads that have been created but not yet started. It's kind of rare that threads every end up on the list. It means the debugger somehow got hold of a ThreadReferences (such as through a local var) and then called a ThreadReference API with it. The usual way it works is when an event finally comes in on the thread, that is when it gets moved from otherThreads to runningThreads or runningVThreads.

Okay, thanks! It would be nice to add a short comment with a couple of sentences to explain this.

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

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