8272096: Exceptions::new_exception can return wrong exception

[coleenp]

I added an assert if Exceptions::new_exception is called with a pending exception and fixed the places where it is called with a pending exception. That leaves only two possible exceptions. I left the product mode code in to return the pending exception if allocating the exception message doesn't thrown OOM because it was always there and seems dubious. Tested with jck tests and tier1-7.

---

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

Issue

• JDK-8272096: Exceptions::new_exception can return wrong exception

Reviewers

• Harold Seigel (@hseigel - Reviewer) ⚠️ Review applies to daf55a4b
• David Holmes (@dholmes-ora - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9492

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

Using diff file

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

[bridgekeeper]

👋 Welcome back coleenp! 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]

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

• hotspot

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

• 02: Full - Incremental (fd1bfeb1)
• 01: Full - Incremental (daf55a4b)
• 00: Full (d5ab48a4)

[hseigel]

The changes look good!
Thanks, Harold

[openjdk]

@coleenp This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8272096: Exceptions::new_exception can return wrong exception

Reviewed-by: hseigel, dholmes

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 65 new commits pushed to the master branch:

• 6cd1c0c: Merge
• 2677dd6: 8289954: C2: Assert failed in PhaseCFG::verify() after JDK-8183390
• 4f3f74c: 8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated predicate failed which is impossible
• 4a4d8ed: 8289801: [IR Framework] Add flags to whitelist which can be used to simulate a specific machine setup like UseAVX
• 5a96a5d: 8289612: Change hotspot/jtreg tests to not use Thread.stop
• b65f7ec: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto implementations
• 6c8d0e6: 8282526: Default icon is not painted properly
• e72742e: 8286172: Create an automated test for JDK-4516019
• b9de0a7: 8284524: Create an automated test for JDK-4422362
• 5ae4320: 8284767: Create an automated test for JDK-4422535
• ... and 55 more: https://git.openjdk.org/jdk/compare/6e18883d8ffd9a7b7d495da05e9859dc1d1a2677...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[coleenp]

Thanks Harold!

[dholmes-ora]

Hi Coleen,

I'm really not sure this is actually addressing the issues/concerns that were raised in the bug report. The assertion is good but otherwise nothing has changed has it?

Every place you changed a THREAD to a CHECK you've changed the existing behaviour of the code. That existing behaviour is dubious because of the missing CHECK but nevertheless it has now been changed, and it isn't always easily discernible exactly how that change will manifest in higher-level code. (It is somewhat disappointing to see so many remaining places that the THREADS/TRAPS cleanup missed :( ).

I think I need to study this one further.

Thanks.

[coleenp]

By changing THREAD to CHECK, I technically didn't change the behavior of the code because the code for new_exception would have thrown the pending exception if it didn't get an OOM allocating the new exception. For the get_u1, get_u2 case, the stream is truncated so the code wasn't going to get much further anyway.
The CR complains of throwing the exception that you get while constructing an exception and that was confusing, but it's the right thing to do. If you get an OOM or StackOverflow creating an exception, you want the OOM or StackOverflow to be returned. See CR for more discussion.

[dholmes-ora]

You have changed behaviour - even if things are actually more correct. For example given:

if (tag == ITEM_Object) {
   u2 class_index = _stream->get_u2(CHECK_NT);
   int nconstants = _cp->length();
   if ((class_index <= 0 || class_index >= nconstants) ||
       (!_cp->tag_at(class_index).is_klass() &&
        !_cp->tag_at(class_index).is_unresolved_klass())) {
     _stream->stackmap_format_error("bad class index", THREAD);
     return VerificationType::bogus_type();
}

If the get_u2 now fails due to classfile truncation then we will throw that exception instead of the "bad class index" fomrat error.

[coleenp]

I actually haven't changed the behavior because instead of "bad class index" in the case of truncation, and the old behavior would throw the truncation exception.
It is more correct.

[dholmes-ora]

Ah now I see sorry. new_exception would have ignored the requested exception and thrown the pending truncation exception instead. Now it is much more clear that, that is what happens.

[dholmes-ora]

Thumbs up from me now - sorry it took me a while to "get it".

Thanks.

[coleenp]

Thanks David for the review and for battling the confusion this code provoked. Hopefully in the end this helps.
/integrate

[openjdk]

Going to push as commit bbc5748.
Since your change was applied there have been 74 commits pushed to the master branch:

• a41b12f: 8290512: G1: Fix typo in allocation statistics log message
• e02627c: 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences"
• 2ff2208: 8289804: Remove redundant stream() call before forEach in jdk.jshell
• f5a7de8: 8290379: Parse error with parenthesized pattern and guard using an array
• 612d8c6: 8290456: remove os::print_statistics()
• d7f0de2: 8290460: Alpine: disable some panama tests that rely on std::thread
• dfbc691: 8289524: Add JFR JIT restart event
• 4e6cd67: 8290000: Bump macOS GitHub actions to macOS 11
• af86cd3: 8290463: Fix several comment typos in sun.security.ec
• 6cd1c0c: Merge
• ... and 64 more: https://git.openjdk.org/jdk/compare/6e18883d8ffd9a7b7d495da05e9859dc1d1a2677...master

Your commit was automatically rebased without conflicts.

[openjdk]

@coleenp Pushed as commit bbc5748.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.