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

[Robbin Ehn]

On Tue, 12 Aug 2025 01:17:27 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:
>> - [x] Linux x64 fastdebug tier 1/2/3/4
>> - [x] Linux aarch64 fastdebug tier 1/2/3/4
>
> Chad Rakoczy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8316694-Final
>  - Lock nmethod::relocate behind experimental flag
>  - Use CompiledICLocker instead of CompiledIC_lock
>  - Fix spacing
>  - Update NMethod.java with immutable data changes
>  - Rename method to nm
>  - Add assert before freeing immutable data
>  - Reorder is_relocatable checks
>  - Require caller to hold locks
>  - Revert is_always_within_branch_range changes
>  - ... and 97 more: https://git.openjdk.org/jdk/compare/9593730a...24c35689

Hey!

@fisk
> Also, do you have any numbers showing if iTLB pressure improved? Or performance improved? Or in general that anything improved? I'm guessing so but I'd like to see some data.

The issue is that some of the major arm manufacturers seems to have missed appendix C in Intel opt manual - "OPTIMIZATION WITH LARGE CODE PAGES".

E.g. running renaissance dotty on a G3 I saw 37% front-ends stall (G2 28%, they made significant improvement to backend on G3, presumably not front-end hence more stalling).

By using less itbl entries we can significant increase ipc on these CPUs.
Simple testing with some eariler version of this got ~10% reduction in frontend stalls (take that number with a grain of salt).
Now if this is correct approach or not, that's is still unclear to me.

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

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