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

[Tom Rodriguez]

On Thu, 22 May 2025 20:23:22 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:
> 
>  - Update tests
>  - Exclude JVMCI methods
>  - Create nmethod relocation stress test

I'd like to clarify a bit what's actually done here.  Some JVMCI compilation can have an associated instance of InstalledCode that has value written into it by hotspot that point at the nmethod* and the verified entry point.  If the mirror object is reclaimed by the garbage collector before the nmethod dies, the mirror field will be cleared.  Graal may read those fields but will never write them.  JVMCI compilations initiated by the CompileBroker will never have an associated mirror.  The mirror object is associated with the method at construction time and will never be changed.  So it's not necessary to exclude all JVMCI compiled nmethods from this relocation, only ones which have a non-null mirror object.

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

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