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

[Chad Rakoczy]

On Mon, 2 Jun 2025 22:43:50 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 test copywrite

Thanks for pointing out the missing JVMTI event publication. I’m currently looking into what’s required to address that, along with JFR event publication that may also have been missed. I’d appreciate hearing others’ thoughts on how critical this is: should we treat it as a blocker for integration, or would it be acceptable to follow up with a separate issue?

We’re hoping to get this into JDK 25, as it would simplify both development and backporting of features related to hot code grouping. That said, if the consensus is that JVMTI/JFR support is essential upfront, this can be delayed until JDK 26.

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

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