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

[Vladimir Kozlov]

On Sat, 22 Nov 2025 00:04:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> 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?

I also assume that trampoline's code instructions can construct far distance address.

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

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