RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2]
Alan Bateman
alanb at openjdk.org
Tue Jul 22 07:04:39 UTC 2025
On Tue, 22 Jul 2025 06:11:45 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.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>
> make workding more like JVMTI spec
Updated version looks good.
-------------
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3041438889
More information about the serviceability-dev
mailing list