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

[Tom Rodriguez]

On Thu, 29 May 2025 23:18:43 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 four additional commits since the last revision:
> 
>  - Add requires GC to tests
>  - Add type for immutable_data_references
>  - Fix incorrect destination set if no trampoline available
>  - Update assert note in nmethod::clear_inline_caches

So this copying keeps the same compile_id, which sort of makes sense but it's also potentially confusing.  What's the plan for how this interacts with flags like PrintNMethods and JVMTI code installation notification?  This is done in nmethod::post_compiled_method which doesn't seem to be used on the new nmethod.  If the reclamation of the old nmethod is performed in the normal fashion, we now have 2 nmethods alive with the same compile_id which could be confusing.  But allocating a new compile_id breaks the connection to the original compile which seems bad too.

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

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