8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown

[plummercj]

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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires a CSR request matching fixVersion 26 to be approved (needs to be created)

Issue

• JDK-8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown (Enhancement - P4)

Reviewers

• Alex Menkov (@alexmenkov - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26335/head:pull/26335
$ git checkout pull/26335

Update a local copy of the PR:
$ git checkout pull/26335
$ git pull https://git.openjdk.org/jdk.git pull/26335/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26335

View PR using the GUI difftool:
$ git pr show -t 26335

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26335.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back cjplummer! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[plummercj]

/csr needed

[openjdk]

@plummercj has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@plummercj please create a CSR request for issue JDK-8309400 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[openjdk]

@plummercj The following label will be automatically applied to this pull request:

• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (05cce179)
• 00: Full (5a079346)

[alexmenkov]

It looks good.
I added cleanup suggestion in the implementation

[alexmenkov]

There is nothing implementation-specific here.
I'd suggest to:

• StackFrameImpl -> StackFrame;
• MethodImpl -> Method;
• remove validateStackFrame at line 408 ('MethodImpl.location()' calls it)

[plummercj]

Are you suggesting renaming the classes? This is a pretty conventional naming when you have classes implementing a spec defined in an interface class. There are a lot more than just StackFrame and Method that are doing this.

[alexmenkov]

Are you suggesting renaming the classes?

No, I mean

Suggested change

	for (int i = 0; i < 2; i++) {
	StackFrameImpl sf;
	try {
	sf = (StackFrameImpl)thread.frame(i);
	} catch (IndexOutOfBoundsException e) {
	// This should never happen, but we need to check for it.
	break;
	}
	sf.validateStackFrame();
	MethodImpl meth = (MethodImpl)sf.location().method();
	if (meth.isNative()) {
	throw new NativeMethodException();
	}
	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();
	}

[plummercj]

Ok. I see now.