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

[Dean Long]

On Mon, 14 Jul 2025 20:34:42 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 does not modify existing code paths and therefore does not benefit much from existing tests. New tests were created to test the new functionality
>> 
>> Additional Testing:
>> - [ ] Linux x64 fastdebug all
>> - [ ] Linux aarch64 fastdebug all
>> - [ ] ...
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert is_always_within_branch_range changes

In jdk25, if stale nmethod was marked as not entrant, we would patch the verified entry point, but we got rid of that in jdk26. So at least in jdk26,  make_not_entrant() shouldn't be changing the nmethod much if at all.  

But let's say another thread is trying to mark the source nmethod as not entrant while nmethod::relocate is running, or soon after.  What is the desired outcome for the newly relocated nmethod?  It seems like any call to make_not_entrant() on the source would also want to do the same on the copy, right?

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

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