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

[Evgeny Astigeevich]

On Wed, 28 May 2025 22:32:23 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1580:
>> 
>>> 1578:     nm_copy->method()->set_code(mh, nm_copy);
>>> 1579:     make_not_used();
>>> 1580:   }
>> 
>> If `nm_copy->method()->code() != this`, we will return the copy which points at a method owning another code. This might be useful. Or we might return a broken copy. 
>> Should we allow this?
>
> That's an interesting point. Now that I think about it I'm curious when `nm_copy->method()->code() != this` would actually happen. It's possible for nmethods that have been recompiled. In that situation though the first nmethod would have been marked as not used and would have failed the `is_relocatable` check in the first place.

The current protocol:
1. The `is_relocatable` check: if `true`, nmethod is in use. `method()` should be non-null.
2. `CodeCache::gc_on_allocation()`: this can invalidate nmethod.
3. Acquire  `Compile_lock`, `CodeCache_lock`: `CodeCache_lock` to prevent CodeCache from modifications. `Compile_lock` blocks deoptimization of nmethod and invalidation of deps.
4. Construct a copy.
5. Invalidate CPU i-cache.
6. Acquire `NMethodState_lock`: the lock prevents nmethod from changing its state.
7. Set the copy as the current code.

I think we need the following the protocol:

1. Invoke `CodeCache::gc_on_allocation()` first.
2. Invoke `is_relocatable`.
3. Acquire  `Compile_lock`, `CodeCache_lock`.
4. Construct a copy.
5. Acquire `NMethodState_lock`.
6. Check nmethod is not mark for deoptimization and is in use and make_in_use.
6.1. Invalidate CPU i-cache.
6.2. Set code
6.3 Make not used
6.4 Return copy
7. Return nullptr

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

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