On Tue, 15 Jul 2025 22:07:40 GMT, Chris Plummer <cjplum...@openjdk.org> 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 CSR and complete testing. This pull request has now been integrated. Changeset: 9041f4c4 Author: Chris Plummer <cjplum...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/9041f4c47f3c9b90abe825f652f572351060c96a Stats: 35 lines in 3 files changed: 5 ins; 10 del; 20 mod 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown Reviewed-by: sspitsyn, alanb, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/26335
