P3
The debug agent could potentially end up with 1000's if not millions of ThreadNodes for vthreads. Currently they are only freed when there is a THREAD_DEATH event, just like for regular threads. The debug agent should attempt to free up ones that are no longer needed. For the most part this means free up a ThreadNode if the thread does not end up getting suspended explicitly (those suspended due to a SUSPEND_ALL can normally still be freed).
There are a number of comments in the debug agent that read "TODO - vthread node cleanup". These are the likely best locations for freeing up the nodes.
Another approach, which hasn't been thought through too much, is to have some sort of periodic task walk the list of vthread ThreadNodes, and free up those that are no longer needed. ThreadNodes don't escape the code in threadControl.c, and it looks like whenever somehow holds a reference to a ThreadNode, the threadLock is held. So this might make it safe to purge ThreadNodes while holding the threadLock.
One other thing to note is that if enumeratevthreads=y is passed to the debug agent, then it needs to keep track of all vthreads, which means keep around a vthread ThreadNodes, so there should be no purging done in this case.
There are a number of comments in the debug agent that read "TODO - vthread node cleanup". These are the likely best locations for freeing up the nodes.
Another approach, which hasn't been thought through too much, is to have some sort of periodic task walk the list of vthread ThreadNodes, and free up those that are no longer needed. ThreadNodes don't escape the code in threadControl.c, and it looks like whenever somehow holds a reference to a ThreadNode, the threadLock is held. So this might make it safe to purge ThreadNodes while holding the threadLock.
One other thing to note is that if enumeratevthreads=y is passed to the debug agent, then it needs to keep track of all vthreads, which means keep around a vthread ThreadNodes, so there should be no purging done in this case.