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