RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors

Alan Bateman alanb at openjdk.org
Mon Jul 21 10:38:42 UTC 2025


On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error.
> 
> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX
> 
>   The implementation is unable to set the frame locals
>   (e.g. the frame at depth is executing a native method).
> 
> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
> 
> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn:
> 
>   The implementation is unable to force the current frame to return
>   (e.g. current frame is executing a native method).
> 
> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.
> 
> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands.

src/java.se/share/data/jdwp/jdwp.spec line 2154:

> 2152:                                      "corresponding to a native method, "
> 2153:                                      "or the implementation is unable to provide this "
> 2154:                                      "functionality on this frame.")

This is okay but I wonder if you've considered nudging it closer to wording in JVMTI ForceEarlyReturnXXX so it would say the implementation is unable to force the frame to return and use a native frame as an example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26336#discussion_r2218791028


More information about the serviceability-dev mailing list