RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7]

[Chris Plummer]

On Tue, 15 Jul 2025 03:00:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details.
>> 
>> It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal.
>> 
>> So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed.
>
> Okay, thanks. This sounds right. 👍

...but JDWP might need some work. StackFrame.SetValues and GetValues only mentions OPAQUE_FRAME for SetValues of a virtual thread. However, I don't think there is anything to prevent them being called on a native frame. You might expect INVALID_SLOT in that case because it would not be possible to specify a valid slot for a local when there are none, but from the code you gave above it looks like slot checks are made after the native method check. So if a combination of a native method and invalid slot results in OPAQUE_FRAME, then we need to update the JDWP spec to reflect this. The other choice is to make JVMTI return INVALID_SLOT when the method is native.

And speaking of INVALID_SLOT, it missing in the JDWP spec for SetValues, but is there for GetValues. It seems that should be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206190118