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

[Chad Rakoczy]

On Thu, 29 May 2025 14:58:00 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

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

I'm not sure it is safe to call `is_relocatable` after calling `CodeCache::gc_on_allocation()`. Like you mentioned it can invalidate the nmethod and any use of it could break

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

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