On Tue, 21 Oct 2025 11:12:45 GMT, Ruben <[email protected]> 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
