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