RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method
Chris Plummer
cjplummer at openjdk.org
Thu Jul 3 18:52:39 UTC 2025
On Thu, 3 Jul 2025 06:05:26 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 functions:
> - `PopFrame`
> - `NotifyFramePop`
> - `ForceEarlyReturn<Type>`
>
> 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
src/hotspot/share/prims/jvmti.xml line 2991:
> 2989: <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 2990: The implementation is unable to pop this frame
> 2991: (e.g. called or calling method is a native method).
Directly below we have special OPAQUE_FRAME language for virtual threads. Do we want to get rid of it since it is now covered by the above language? Note there is also language directly above that discusses suspended virtual threads.
src/hotspot/share/prims/jvmti.xml line 3191:
> 3189: <errors>
> 3190: <error id="JVMTI_ERROR_OPAQUE_FRAME">
> 3191: The implementation is unable to force current frame to return
Suggestion:
The implementation is unable to force the current frame to return
src/hotspot/share/prims/jvmti.xml line 3194:
> 3192: (e.g. current frame is executing a native method).
> 3193: </error>
> 3194: <error id="JVMTI_ERROR_OPAQUE_FRAME">
Do we still need this section? Same question for repeated sections below.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183507709
PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183513041
PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183515227
More information about the serviceability-dev
mailing list