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

Evgeny Astigeevich eastigeevich at openjdk.org
Thu Jun 26 10:43:45 UTC 2025


On Wed, 25 Jun 2025 22:32:24 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 only slightly modifies existing code paths and therefore does not benefit much from existing tests. New tests were created to test the new functionality
>> 
>> Additional Testing:
>> - [ ] Linux x64 fastdebug all
>> - [ ] Linux aarch64 fastdebug all
>> - [ ] ...
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8316694-Final
>  - Update how call sites are fixed
>  - Merge remote-tracking branch 'origin/master' into JDK-8316694-Final
>  - Fix pointer printing
>  - Use set_destination_mt_safe
>  - Print address as pointer
>  - Use new _metadata_size instead of _jvmci_data_size
>  - Merge remote-tracking branch 'origin/master' into JDK-8316694-Final
>  - Only check branch distance for aarch64 and riscv
>  - Move far branch fix to fix_relocation_after_move
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/f799cf18...70e4164e

src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp line 90:

> 88:   // Patch the constant in the call's trampoline stub.
> 89:   address trampoline_stub_addr = get_trampoline();
> 90:   if (trampoline_stub_addr != nullptr && dest != trampoline_stub_addr) {

I think you will not need the checks if you rewrite the code as follows:
```c++
address addr_call = ...;
assert();

if (!Assembler::reachable_from_branch_at(addr_call, dest)) {
  address trampoline_stub_addr = get_trampoline();
  assert (trampoline_stub_addr != nullptr, "we need a trampoline");
  assert (! is_NativeCallTrampolineStub_at(dest), "chained trampolines");
  nativeCallTrampolineStub_at(trampoline_stub_addr)->set_destination(dest);
  dest = trampoline_stub_addr;
}
set_destination(dest);
ICache::invalidate_range(addr_call, instruction_size);


If `dest` is a trampoline in the current nmethod, it is always reachable. So you will not go into setting trampoline's target to itself. Also we will call `get_trampoline`, which involves `CodeCache::find_blob` and ` a traversal of relocations, only if we need a trampoline.

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

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


More information about the hotspot-compiler-dev mailing list