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

[Evgeny Astigeevich]

On Tue, 26 Aug 2025 10:03:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix WB_RelocateNMethodFromAddr to not use stale nmethod pointer
>
> A side comment, which I don't find it discussed in JEP or in the issues. (maybe I just missed it)
> There can also be a significant performance improvement using direct jumps versus using indirect jump and reduced memory pressure. E.g. a direct BL vs BL to LDR + BR + <8 byte address>.
> 
> Hence it would be good to place hot methods within the hot area in "call sequences", as an application may have many hot methods totally unrelated to each other. This also means you really would like to have e.g. vtable stub in reach of BL in above case to get the most out of it.

@robehn 

> A side comment, which I don't find it discussed in JEP or in the issues. (maybe I just missed it) There can also be a significant performance improvement using direct jumps versus using indirect jump and reduced memory pressure. E.g. a direct BL vs BL to LDR + BR + <8 byte address>.

Java calls, which are indirect in the original nmethod, will become direct if callees get close to the copy.
Java calls, which are direct in the original nmethod, will become indirect if callees get far from the copy.
We can do this because we use trampolines for Java calls.

Runtime calls, which are indirect in the original nmethod, will stay indirect. Whether runtime calls are direct or indirect depends on the static configuration of CodeCache not on a placement of nmethod in CodeCache. See `target_needs_far_branch()` in `src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp`. We don't use trampolines for runtime calls. Maybe it's worth to switch to use trampolines for runtime calls as well. We have a mechanism of shared trampolines. Runtime calls are always direct for the default CodeCache configuration: 240MB, three code heaps.

> 
> Hence it would be good to place hot methods within the hot area in "call sequences", as an application may have many hot methods totally unrelated to each other.

We are working on an algorithm to identify candidates to be placed together in the hot code heap. It can consider putting together a caller and its callees in the hot code heap.

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

PR Comment: https://git.openjdk.org/jdk/pull/23573#issuecomment-3292817263