On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <[email protected]> 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
