RFR: 8371046: Segfault in compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC

[Vladimir Kozlov]

On Fri, 21 Nov 2025 22:22:53 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1508:
>> 
>>> 1506: #ifdef USE_TRAMPOLINE_STUB_FIX_OWNER
>>> 1507:     // Direct calls may no longer be in range and the use of a trampoline may now be required.
>>> 1508:     // Instead, allow trampoline relocations to update their owners and perform the necessary checks.
>> 
>> `Instead` is wrong word here I think. May be `Otherwise`.
>> 
>> Also where you add trampoline in new nmethod's copy if needed? I don't see it in `fix_relocation_after_move()`.
>
> We do not add trampolines to the new nmethod if they were not present in the original.
> 
> Does this comment better describe the need to do this?
> 
> // A direct call whose destination was within the maximum branch range may now
> // be out of range after the nmethod is moved.
> //
> // CallRelocation::fix_relocation_after_move() does not perform range checks and
> // assumes that the call target is always directly reachable. If we were to call
> // it unconditionally, it could incorrectly rewrite a call site whose target now
> // requires a trampoline, leaving the call out of range.
> //
> // When a call site has an associated trampoline, we skip the normal call
> // relocation here. The corresponding trampoline_stub_Relocation will handle both
> // the call site and the trampoline, including performing the required range
> // checks and updating the call to branch through the trampoline if required.
> //
> // If no trampoline exists for the call, we know the target remains within the
> // direct-branch range and CallRelocation::fix_relocation_after_move() is safe.

Okay, I now get it that the comments try to explain why we need to call fix_relocation_after_move().
I am not questioning this. My question is about the case when you can't patch address in existing instructions set. I assume you should bailout from this cloning or you should always generate instruction set pin original nmethod assuming far distance.

Okay, there are 3 cases as I understand:
  1. There was trampoline call in original nmethod. We do nothing here (hit `continue`) because the trampoline code will be updated (I see its is guarded by `#ifdef USE_TRAMPOLINE_STUB_FIX_OWNER`). Good.
  2. There was no trampoline call in original nmethod and new nmethod still in range of destination address and set of instructions allows `fix_relocation_after_move()` correctly update destination.
  3. There was no trampoline call in original nmethod and new nmethod not in range of destination address and existing instruction set is not enough to reconstruct address - there is need for trampoline call or more complex set of instruction to construct destination.
  
My question is how you handle 3rd case? And how you distinguish 2 and 3 cases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28241#discussion_r2551327903