RFR: 8321509: False positive in get_trampoline fast path causes crash [v3]

[Andrew Dinn]

On Wed, 10 Jul 2024 22:30:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> > So for Leyden it sounds like you need to change is_always_within_branch_range().
>>> 
>>> Or perhaps just adapt MacroAssembler::far_branches(). It returns false if the code cache max range exceeds branch_range. In Leyden we can make it return false when we are generating AOT code.
>> 
>> We might need to adapt [`target_needs_far_branch`](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L677) for AOT code generation.
>
> I'll wait until tomorrow to push, in case there are still concerns/questions from @eastig or @adinn .

@dean-long I'm ok with Valdimir's suggestion just to include the "optimization" check. This fixes the problem with processing relocations when saving/restoring AOT code including in generated stub routines.

n.b. unlike nmethods, generated stub code can contain direct pc-rel branches within the buffer which do not target a trampoline. This happens in the arraycopy stub as one example. However, I don't believe this invalidates your assumptions as to how to handle buffer resize events because buffers used for stubs are pre-allocated large enough to avoid the need for resizing.

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

PR Comment: https://git.openjdk.org/jdk/pull/19796#issuecomment-2222464139