RFR: 8343789: Move mutable nmethod data out of CodeCache [v10]
Boris Ulasevich
bulasevich at openjdk.org
Thu Feb 20 20:50:57 UTC 2025
On Mon, 17 Feb 2025 18:47:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>>> Looks good. I will submit testing.
>>
>> Thank you!
>>
>> The change is not yet ready for final testing. I still need to remove my raw access workaround in nmethod::oop_at and rebase onto #23512 once it has been integrated.
>
> @bulasevich my an other PR #23533 is ready. It will conflict with your changes. Are you okay if I push it first?
@vnkozlov, @dean-long, @theRealAph, @stefank
I have to note that my change causes a performance regression in the DaCapo luindex benchmark on AArch64 when using UseShenandoahGC mode. The regression is solely due to the additional adrp+movk instructions required to access oops from the compiled code. My intention was to reduce the nmethod size by moving oops out of the code cache. While this does reduce the space occupied by oops data, on AArch64 with Shenandoah, the extra instructions needed to access oops add back approximately 1% of the total nmethod size, effectively canceling the reduction achieved by moving oops. Given this, I now think it would be better to keep oops in nmethod while still moving other data (relocations, metadata, jvmci_data) out.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21276#issuecomment-2672645456
More information about the hotspot-compiler-dev
mailing list