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

[Ruben]

On Mon, 13 Oct 2025 11:45:02 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 with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    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.

I've also looked into the `far_jump` vs `far_call` issue - attempting to identify why tests on my side didn't catch this.
It appears that normally methods load the return address from stack to `LR` before using `RET`, so by chance the `LR` happens to point to the entry point of the stub code upon entering the stub code.

I've managed to reproduce a situation when it isn't the case - deoptimization of parked virtual threads - where the control flow is transferred to the deoptimization handler stub code via the signal handler. In this case, the LR is pointing to the post-call sequence (which was patched to cause a `SIGILL`) within the same method. However, even in this case, the test completed successfully as apparently the `fetch_unroll_info_helper` is designed in a way that can handle both frames pointing to deoptimized methods and frames to non-deoptimized methods where execution should continue in interpreter (for example, uncommon trap).

It might be beneficial to add an assertion in the `fetch_unroll_info_helper` that ensures, for case `exec_mode` is `Unpack_deopt` (and potentially, for `Unpack_exception` too) that the LR is indeed pointing to the deoptimization handler stub code.

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

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