RFR: 8365047: Remove exception handler stub code in C2 [v4]

[Ruben]

On Fri, 12 Sep 2025 16:36:56 GMT, Ruben <duke at openjdk.org> wrote:

>> 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.
>
> Ruben has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"

I'm planning to update the PR soon. The issue on s390 is likely due to the deoptimization blob still adjusting the return address value, which isn't needed anymore. On PPC64, the issue is probably due to the C1-generated deoptimization handler stub code wasn't adjusted.

It seems that a call might be at the very end of the main code section, for example, due to an uncommon trap call sequence. Those aren't supposed to return. However, the issue might not reveal itself where post-call NOP sequences are implemented: there would always be the sequence emitted after the call instruction.

Where the post-call NOP sequences are implemented, they're emitted as long as "continuations" are enabled. Disabling continuations appears to be an experimental option. Would it be valid to assume that the configurations with disabled continuations have to be supported?

As far as I understand, the post-call NOP sequences aren't implemented for s390 and for AArch32.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3325702198