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.

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

Commit messages:
 - fix OpaqueFrameException related issues

Changes: https://git.openjdk.org/jdk/pull/26335/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309400
  Stats: 35 lines in 3 files changed: 5 ins; 9 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/26335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26335/head:pull/26335

PR: https://git.openjdk.org/jdk/pull/26335

Reply via email to