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

[Boris Ulasevich]

On Thu, 13 Mar 2025 23:01:10 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 PRODUCT check
>  - Remove isRelocation flag
>  - Replace copy constructor with clone function

src/hotspot/share/code/nmethod.cpp line 1404:

> 1402:   memcpy(nm_copy, this, size());
> 1403: 
> 1404:   // Allocate memory and copy immutable data from C heap

A new immutable data block is allocated for the new nmethod. Would it be possible to reuse the old one instead? This could help reduce memory allocation overhead, though it would make the logic more complicated. The destroyed nmethod should consider whether it is the last one holding the immutable nmethod blob. Probably, concurrent modification issues could arise. What do you think?

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

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