On Tue, 15 Jul 2025 22:07:40 GMT, Chris Plummer <[email protected]> wrote:
> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal
> with JDWP OPAQUE_FRAME error.
>
> Before virtual threads, OpaqueFrameException did not exist and these API
> always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned.
> For virtual threads OpaqueFrameException was added to handle the case where a
> virtual thread was not suspended at an event, so the JDI implementation was
> updated to throw OpaqueFrameException if it detected that a native method was
> not the cause. It turns out however that JVMTI (and therefore JDWP) can
> return OPAQUE_FRAME error for reasons other than a native method or the
> special virtual thread case, and for platform threads we were incorrectly
> throwing NativeMethodException in these cases. This PR fixes that. For
> platform threads we now only throw NativeMethodException if a native method
> is detected, and otherwise throw OpaqueFrameException.
>
> The spec language is also being cleaned up to better align with JVMTI. Rather
> than calling out all the reasons for OpaqueFrameException, a more generic
> explanation is given.
>
> This is somewhat of a preliminary PR so I can get some feedback. I still need
> to do a CR and complete testing.
src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 412:
> 410: if (meth.isNative()) {
> 411: throw new NativeMethodException();
> 412: }
> Are you suggesting renaming the classes?
No, I mean
Suggestion:
for (int i = 0; i < 2; i++) {
StackFrame sf;
try {
sf = thread.frame(i);
} catch (IndexOutOfBoundsException e) {
// This should never happen, but we need to check for
it.
break;
}
Method meth = sf.location().method();
if (meth.isNative()) {
throw new NativeMethodException();
}
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2209033573
