8371458: [REDO] Remove exception handler stub code in C2

[ruben-arm]

The original fix JDK-8365047 was backed out by JDK-8371388, this is the REDO.

The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.

According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 2 Reviewers)

Issue

• JDK-8371458: [REDO] Remove exception handler stub code in C2 (Enhancement - P4)

Reviewers

• Martin Doerr (@TheRealMDoerr - Reviewer)

Contributors

• Martin Doerr <mdoerr@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28192

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[ruben-arm]

/contributor add @TheRealMDoerr

[bridgekeeper]

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

@ruben-arm This change is no longer ready for integration - check the PR body for details.

[openjdk]

@ruben-arm
Contributor Martin Doerr <mdoerr@openjdk.org> successfully added.

[openjdk]

@ruben-arm The following labels will be automatically applied to this pull request:

• hotspot
• serviceability

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

[mlbridge]

Webrevs

• 01: Full - Incremental (20cc58a3)
• 00: Full (7bb43523)

[ruben-arm]

Thanks @ruben-arm. Let's go with this clean back out for now - testing just came back clean. Once you have the REDO ready, I can submit some more sophisticated testing to make sure it addresses the issues we're seeing.

@TobiHartmann, I would appreciate it if you could initiate the extended testing for this PR.

[TobiHartmann]

Sure, I submitted testing.

[vnkozlov]

@ruben-arm what was the issue in the original changes?

[ruben-arm]

@vnkozlov, the NativePostCallNop::check

jdk/src/hotspot/cpu/x86/nativeInst_x86.hpp

Line 584 in e34a831

bool check() const { return int_at(0) == 0x841f0f; }

was reading 4 bytes from the perceived call site.

That works when the check happens for an actual call site, as the post-call NOP sequence is always longer than 4 bytes.
However, it fails in case the return address in the stack frame, during deoptimization, is patched to point to the deoptimization stub code entry point.

With the change, the distance between the entry point and end of code blob can now be just 2 bytes - consequently the 4-bytes read would read outside the code blob.
The proposed fix is to split the read in the post-call NOP check into two 2-byte reads. If first read+comparison doesn't confirm it might be a post-call NOP sequence (it never will for the deoptimization stub code entry point) the second read wouldn't happen.

I initially missed this issue - having incorrectly concluded that the jmp at the entry point will take 5 bytes in size instead of 2 bytes.

7bb4352 should address this issue by splitting the faulting read into two. It also adjusts the expected size of deoptimization handler stub code to 7 bytes in total instead of the incorrect estimate of 10 bytes.

[TobiHartmann]

Sure, I submitted testing.

All testing passed. I leave it to the original reviewers to re-review.

[TheRealMDoerr]

I haven't checked the deopt handler size on x86. Otherwise, it still looks good to me.

[TheRealMDoerr]

Maybe a comment would be nice.

[ruben-arm]

Thanks for the suggestion. Would the comments added at 20cc58a be suitable?

[openjdk]

⚠️ @ruben-arm the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout pr-8365047
$ git commit --author='Preferred Full Name <you@example.com>' --allow-empty -m 'Update full name'
$ git push

[ruben-arm]

Thanks, @TobiHartmann, for the extra tests, and apologies for missing this in the original PR.

@TheRealMDoerr, I will update the PR to add comments.

I am exploring a possibility to add a unit test for this issue, but I have not identified a deterministic way to make the deopt handler stub end at a page boundary.

[TobiHartmann]

/reviewers 2 reviewer

[openjdk]

@TobiHartmann
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 Reviewers).

[ruben-arm]

I am planning to update this PR today to include the comments.
However, I still have not identified a way to ensure the deopt handler stub ends at a page boundary in a unit test.

[ruben-arm]

However, I still have not identified a way to ensure the deopt handler stub ends at a page boundary in a unit test.

The latest update implements an alternative way to detect the failure early during testing - via the newly added assertion in the emit_deopt_handler.

@adinn, @dean-long, @TheRealMDoerr, would it be possible for you to review the latest version of the PR?

Is there any additional testing you would recommend to perform before this can be integrated?

[TheRealMDoerr]

I think assertions would be sufficient in C1 instead of guarantee. But, ok. I'll put it into our test queue.