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

[Evgeny Astigeevich]

On Fri, 30 May 2025 19:25:51 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> 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.

As we are not compiling, `compile_id` should stay the same. Yes, we need to add some logging: `log_info(codecache)` and `PrintNMethods`. 

According to https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#CompiledMethodLoad, compile methods can be moved. We need to generate events if it happens:
>If it is moved, the [CompiledMethodUnload](https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#CompiledMethodUnload) event is sent, followed by a new CompiledMethodLoad event.

 > we now have 2 nmethods alive with the same compile_id which could be confusing.

If `compile_id` is interpreted as id of nmethod, it is confusing. Comment to `nmethod::_compile_id`: https://github.com/openjdk/jdk/blob/aea2837143289800cfbb7044de4f105e87e233ff/src/hotspot/share/code/nmethod.hpp#L259

According to it, it is id of a compilation task. In such case there should be no confusion.

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

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