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

[Chad Rakoczy]

On Thu, 21 Aug 2025 17:10:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> 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.
>> 
>> Okay that sounds quite promising.
>> 
>> So what is the driver for this relocation in the JVM, which makes sure hot nmethods get moved together?
>
>> So what is the driver for this relocation in the JVM, which makes sure hot nmethods get moved together?
> 
> @fisk, next RFE  [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205) will "drive" nmethod relocation based on their hotness. It is similar AFAIK to what you implemented back in Leyden repo to create list of hot nmethods to cache.
> 
> 
> We can a sampling thread which uses the thread-local handshake framework. An example of such a thread is the Sweeper: https://github.com/openjdk/jdk17u/blob/master/src/hotspot/share/runtime/sweeper.hpp which was used to detect active nmethods.

@vnkozlov Could you give the changes another look before integration since I had to resolve a minor merge conflict? I don’t think re-review from others is necessary, but let me know if you feel otherwise.

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

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