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

[Andrew Dinn]

On Tue, 21 Oct 2025 11:12:45 GMT, Ruben <duke at openjdk.org> wrote:

> I believe the specific issue revealed in the failed test is due to the NativePostCallNop::check is trying to read both NOP and MOVK in a combined 8-byte read, which requires at least two instructions after the perceived call site to be readable. In this case, the deoptimization handler stub code has only one valid instruction after the entry point. As the stub code is positioned right at the end of a page, presumably with the next page not mapped, the combined read fails. A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.
> 
> This issue appears to be potentially independent from the far_jump being used instead of far_call.

You may well be correct in your assumption that the error is happening in `NativePostCallNop::check()`. I believe the check for in deopt may well do that. However, the `check()` method does not do a combined 8 byte read. What it does is a 4 byte read at the supplied pc (i.e one instruction's worth of data) to test whether those bytes encode a `nop` instruction. As the comment in the check method makes clear there is no need to test for a following `movz` because the JIT never generates a `bl; nop` or `brl; nop` that is not then followed by a `movz`.

The problem in this error case appears to be that the pc address being tested is `0x0000f7cf03c60000` which is indeed just off the end of the mapped heap, 2 words beyond the branch instruction that took us into the deopt handling code. That would indicate that this value somehow got installed into the link register `lr`. Now this register would have been written with `0x0000f7cf03c5fffc` if the C1 code had used `far_call`. Since we got to the check via a `far_jump` unfortunately `lr` did not get updated with the expected return address. It may be that `0x0000f7cf03c60000` ended up there by chance because `lr` was being used by the JITted code as a data register (that can happen).

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

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