On Tue, 15 Jul 2025 22:50:00 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. 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
