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

[Evgeny Astigeevich]

On Thu, 21 Aug 2025 14:56:30 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> 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.

@robehn @fisk 

I added a microbenchmark demonstrating performance impact of the sparse CodeCache: https://github.com/openjdk/jdk/pull/23831
It shows the code sparsity affects both Intel and Graviton CPUs. In case of Graviton CPUs you can measure the code sparsity: r11c counter per 1000 instructions. BTW there might be no ITLB misses or minor ones in the case of the code sparsity.

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

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