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

[Chad Rakoczy]

On Thu, 21 Aug 2025 12:12:00 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> In fact, it might make sense to make it not entrant instead of not used to that end, so the GC understands this should be nuked.

Could you explain what you mean by this? Not used is not entrant. 

> If we actually free up the old nmethod, there is not much of a sharing opportunity here.

The goal is to eliminate an unneeded copy. What is being done is less "sharing" and more of a hand off of ownership from the old to the new as the GC will clean up the old eventually. When that happens the old should know not to free the immutable data memory.

> Even if we want this micro optimization, is there any reason it wouldn't just be a normal field so we can get rid of this special handling in the byte blobs?

That is the motivation for [JDK-8358213](https://bugs.openjdk.org/browse/JDK-8358213). I suppose we could have a field in `nmethod` to know if it should free its immutable data instead of storing a reference counter in the immutable data itself. I don't have a strong argument for either approach.

> src/hotspot/share/runtime/globals.hpp line 1567:
> 
>> 1565:           range(0, 100)                                                     \
>> 1566:                                                                             \
>> 1567:   product(bool, NMethodRelocation, false, EXPERIMENTAL,                     \
> 
> Why is this only available behind an experimental JVM flag?

This was requested by @vnkozlov so others know `nmethod::relocate` is still experimental

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

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