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

[Chris Plummer]

On Fri, 11 Jul 2025 20:08:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent.
>> This impacts the following JVMTI spec sections:
>>   - `PopFrame`
>>   - `NotifyFramePop`
>>   - `ForceEarlyReturn<Type>`
>>   - `GetLocal<Type>`
>>   - `SetLocal<Type>`
>>   - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code
>>   
>> A related CSR is going to be filed for this spec update.
>> 
>> Testing:
>>  - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge
>  - review: minor tweak of previous change
>  - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function
>  - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions
>  - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions
>  - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function
>  - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method

src/hotspot/share/prims/jvmti.xml line 5904:

> 5902:         <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 5903:           The implementation is unable to get the frame locals
> 5904:           (e.g. the frame at <code>depth</code> is executing a native method).

Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT .

For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads.

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

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