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

[Chad Rakoczy]

On Mon, 21 Apr 2025 23:55:02 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 three additional commits since the last revision:
> 
>  - Add null check in StressNMethodRelocation
>  - Hold Compile_lock
>  - Use methodHandle for VM_Operation so pointer is not stale

I’ve made several adjustments to address the key concerns. The relocation logic now avoids copying stale or invalid metadata by using MethodHandles to maintain valid references. This approach holds the corresponding method for the nmethod being relocated, which should be safe since we only relocate Java methods that have associated method objects. I’ve also added safety checks, including one to prevent relocating unloading nmethods. The relocation is now “opt-in,” creating a new nmethod and copying only the necessary values, which should mitigate the risk of unintentionally carrying over invalid state. I’m still investigating the JVMCI-specific behavior, particularly how the nmethod mirror is handled, and will follow up once I have a clearer understanding.

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

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