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

[Chad Rakoczy]

On Wed, 16 Jul 2025 06:59:06 GMT, Dean Long <dlong at openjdk.org> wrote:

> I can't find who posted this and what lines it refers to. If it refers to nmethod::relocate, I don't think the lock is needed after 8358821, because nobody will be patching the relocations.

The [comment](https://github.com/openjdk/jdk/pull/23573#issuecomment-2831542576) was from @fisk on an old revision but it was because `NMethodState_lock` was being held for the entirety of `nmethod::relocate` as opposed to just when the the state is updated. However I'm curious about the case where the nmethod we are attempting to relocate gets updated. For example

1. Call nmethod relocate
2. Check is_in_use()
3. Original nmethod marked not entrant from somewhere else in JVM
4. Perform relocation on stale nmethod

I believe we need some way to guarantee the source does not change during relocation.

 

> The source nmethod? I don't see how that would cause a problem for that small block of code. All it does to the source is call make_not_used().

I'm interested in the case where something else invalidates the source nmethod during relocation. It can't be evicted from the code cache because the `CodeCache_lock` is held during relocation but that doesn't stop another thread from marking it not entrant

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

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