RFR: 8316694: Implement relocation of nmethod within CodeCache [v13]

[Dean Long]

On Thu, 24 Apr 2025 23:25:11 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> This PR introduces a new function to replace nmethods, addressing [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). It enables the creation of new nmethods from existing ones, allowing method relocation in the code heap and supporting [JDK-8328186](https://bugs.openjdk.org/browse/JDK-8328186).
>> 
>> When an nmethod is replaced, a deep copy is performed. The corresponding Java method is updated to reference the new nmethod, while the old one is marked as unused. The garbage collector handles final cleanup and deallocation.
>> 
>> This change does not modify existing code paths and therefore does not benefit much from existing tests. New tests were created and confirmed to pass on x64/aarch64 for slowdebug/fastdebug/release.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix branch range check

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 940:

> 938: 
> 939:   static bool reachable_from_branch_at(address branch, address target, bool use_max=false) {
> 940:     return uabs(target - branch) < (use_max ? max_branch_range : branch_range);

This might be the wrong approach.  Using the max range will make the assert below fail less often in debug builds, but disables the stress feature of using the shorter 2M range.

src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp line 86:

> 84:     if (!Assembler::reachable_from_branch_at(addr(), x, true)) {
> 85:       address trampoline = call->get_trampoline();
> 86:       assert(trampoline != nullptr, "branch is too large with no available trampoline");

Doesn't this mean any nmethod relocation can cause the JVM to crash if there is no trampoline?  Or are you creating new trampoline stubs in the relocated destination as needed (and deleting trampoline stubs that are no longer needed)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2059381735
PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2059380801