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 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-8371458: [REDO] Remove exception handler stub code in C2 (Enhancement - P4)

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]

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

[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

• 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.