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

Serguei Spitsyn sspitsyn at openjdk.org
Thu Jul 17 23:05:48 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.

This looks good. Also, I'll wait for CSR to review.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3031242406


More information about the serviceability-dev mailing list