RFR: 8316694: Implement relocation of nmethod within CodeCache

[Cesar Soares Lucas]

On Tue, 11 Feb 2025 22:05:13 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.

test/hotspot/jtreg/compiler/whitebox/ReplaceNMethod.java line 65:

> 63:         compile();
> 64: 
> 65:         checkCompiled();

Looks like the test will fail if the method is currently only queued for compilation, right? Being queued for compilation isn't an error in this situation AFAIU.

test/hotspot/jtreg/compiler/whitebox/ReplaceNMethodVerifyNoRecomp.java line 123:

> 121: 
> 122:             // Get newly created nmethod
> 123:             NMethod origNmethod = NMethod.get(method, false);

What do you think about adding a loop around the copy/replacement of the method? I think it would make the test more convincing and may not impact it's execution time that much.

test/hotspot/jtreg/compiler/whitebox/ReplaceNMethodVerifyNoRecomp.java line 147:

> 145:         // Call function multiple times to trigger compilation
> 146:         private static void callFunction() {
> 147:             for (int i = 0; i < CompilerWhiteBoxTest.THRESHOLD; i++) {

NIT: I'd make the loop go up to `THRESHOLD+N` just to be cautious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r1955013437
PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r1955007955
PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r1955010779