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

[Robbin Ehn]

On Fri, 22 Aug 2025 23:35:45 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 does not modify existing code paths and therefore does not benefit much from existing tests. New tests were created to test the new functionality
>> 
>> Additional Testing:
>> - [x] Linux x64 fastdebug tier 1/2/3/4
>> - [x] Linux aarch64 fastdebug tier 1/2/3/4
>
> 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.

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

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