RFR: 8372957: After JDK-8282441 JDWP might allow some invalid FrameIDs to be used

[Chris Plummer]

On Tue, 2 Dec 2025 20:40:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> [JDK-8282441](https://bugs.openjdk.org/browse/JDK-8282441) added freeing of ThreadNodes for some vthreads that are still running. They are only suppose to be freed if the ThreadNode contains no state information that needs to be maintained. There appears to be a bug in the current logic, allowing the loss of the ThreadNode frameGeneration value when it should be retained. Details in first comment.
> 
> Tested with by running all tier5 CI svc tests, which includes virtual thread testing.

frameGeneration is used to generate FrameIDs for the thread. FrameIDs are used for accessing stack frame contents. For example StackFrame.GetValues. The FrameID is generated by ThreadReference.Frames, with each frame in the returned array having a unique FrameID that is composed of the stack depth of the frame combined with the thread's current frameGeneration value. When a FrameID is passed to the debug agent, it validates that the frameGeneration in the FrameID is equal to the thread's current frameGeneration value. frameGeneration is incremented each time the thread is resumed, effectively invalidating any FrameIDs already generated for the thread.

Currently frameGeneration is ignored when deciding if a ThreadNode can be freed. This means if the ThreadNode is recreated later on, frameGeneration will return to its default of 0, possibly allowing stale FrameIDs to become valid again.

At first I was thinking I need to retain ThreadNodes whenever frameGeneration is incremented. That is both overkill and not enough at the same time. It is overkill because for any thread that has a resume done on it, we would need to retain the ThreadNode even if there are no FrameIDs generated for it. It is also not enough because if frameGeneration is 0 and there was a FrameID generated using it, and a VM.Resume is done while the ThreadNode is not allocated, the FrameID should become invalid at that point but it won't because there is no ThreadNode to increment frameGeneration on.

The better solution here is to set a flag on the ThreadNode whenever a FrameID is created for the thread. This is far less common than doing resumes, and should still allow for most ThreadNodes to be freed.

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

PR Comment: https://git.openjdk.org/jdk/pull/28616#issuecomment-3603881146