On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer <cjplum...@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 Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3044807888
