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

Chad Rakoczy duke at openjdk.org
Sat Nov 22 00:46:39 UTC 2025


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

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

> My question is how you handle 3rd case? And how you distinguish 2 and 3 cases?

We should never run into the 3rd case. If a trampoline _may_ be needed it will be there.

A trampoline will not be generated only if the destination is known to always be reachable. Here are some situations where this could happen:
- no far branches (code cache size <= branch range)
- runtime call is reachable from anywhere in code cache 
   - (code cache begin - runtime call <= branch range) && (code cache end - runtime call <= branch range)

Whether or not a trampoline is generated is dependent on the callee destination not the caller address. So we can't have the case where a trampoline is needed for a given call but it doesn't exist.

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

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


More information about the graal-dev mailing list