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

Chris Plummer cjplummer at openjdk.org
Tue Jul 15 23:45:38 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.

Ping. just triggering first email to serviceability-dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/26336#issuecomment-3076084500


More information about the serviceability-dev mailing list