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

[Chad Rakoczy]

On Thu, 8 May 2025 19:31:43 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> This PR introduces a new function to replace nmethods, addressing [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694). It enables the creation of new nmethods from existing ones, allowing method relocation in the code heap and supporting [JDK-8328186](https://bugs.openjdk.org/browse/JDK-8328186).
>> 
>> When an nmethod is replaced, a deep copy is performed. The corresponding Java method is updated to reference the new nmethod, while the old one is marked as unused. The garbage collector handles final cleanup and deallocation.
>> 
>> This change does not modify existing code paths and therefore does not benefit much from existing tests. New tests were created and confirmed to pass on x64/aarch64 for slowdebug/fastdebug/release.
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 54 additional commits since the last revision:
> 
>  - Fix null check
>  - Remove unnecessary include
>  - Add nullptr check to relocate
>  - Fix JVMCI nmethod data
>  - Unexclude JVMCI methods
>  - Add relocate_nmethod_mirror
>  - Only hold NMethodState_lock when needed
>  - Exclude JVMCI nmethods
>  - Remove StressNMethodRelocation
>  - Fix branch_range revert
>  - ... and 44 more: https://git.openjdk.org/jdk/compare/1666d4f3...9ca3563a

JVMCI compiled nmethods have been excluded from relocation due to concerns about safely updating their mirror fields. Graal can deoptimize methods and update these fields without acquiring locks, which introduces a potential race condition between relocation and field resetting.

One possible solution is to introduce a lock when updating these fields. The lock must not block safepoints, since updates can be triggered from Java code. However, this would require that mirror updates do not hold any `_no_safepoint_check` locks. This is currently not the case, such as during deoptimization caused by uncommon traps ([source](https://github.com/openjdk/jdk/blob/139a05d05959a84541a29dfae6151f92ce579ae6/src/hotspot/share/runtime/deoptimization.cpp#L2456)).

Another potential approach is to perform relocation at a safepoint, which would guarantee that Graal is not concurrently updating the fields.

For now, excluding JVMCI methods from relocation appears to be the safest option. I’m in the process of writing a JBS issue to track this and eventually re-enable relocation for these methods. If anyone has suggestions for alternative solutions or improvements, I’d greatly appreciate the feedback.

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

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