RFR: 8316694: Implement relocation of nmethod within CodeCache [v32]
Dean Long
dlong at openjdk.org
Thu Jul 10 00:09:50 UTC 2025
On Wed, 9 Jul 2025 00:29:58 GMT, Chad Rakoczy <duke at openjdk.org> wrote:
>> The original motivation was to address far call sites. After relocation, some calls that previously didn't require a trampoline might now need one, hence the introduction of the `be_safe` parameter. However, upon further review, this change is unnecessary. The method `trampoline_stub_Relocation::fix_relocation_after_move` already updates the owner and contains the logic to determine whether a direct call can be performed. Therefore, we can skip invoking `CallRelocation::fix_relocation_after_move` for calls that use trampolines, as all required adjustments will be handled correctly by the trampoline relocations. ([Reference](https://github.com/chadrako/jdk/blob/0f4ff9646d1f7f43214c5ccd4bbe572fffd08d16/src/hotspot/share/code/nmethod.cpp#L1547-L1556))
>
> @dean-long What are your thoughts on this solution?
The logic looks fine, but I don't think it belongs in shared code. Why not have a new fix_relocation_after_xxx() that is platform-specific? For most platforms it can just delegate to fix_relocation_after_move().
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2196224362
More information about the hotspot-compiler-dev
mailing list