RFR: 8356085: AArch64: compiler stub buffer size wrongly depends on ZGC
Andrew Dinn
adinn at openjdk.org
Wed May 7 15:02:23 UTC 2025
On Wed, 7 May 2025 14:13:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> Should we do this for all platforms?
That's quite an interesting question. The immediate answer is no. Only aarch64 was specifying extra space for ZGC. So, there is nothing more to do.
The more interesting question is
Q1) Why did aarch64 originally do this?
The bonus question is
Q2) Which ports allocate extra space for ZGC in other stubgen buffers?
Q1. The only reason a buffer may need more space for ZGC is because the stubs it includes perform object reads or writes -- ZGC injects more barrier instructions than other GCs. It seems that the only candidates are the array copy stubs. On aarch64 these used to be generated in the compiler stubs buffer but the reorg moved them to final stubs as per other arches. That's why the extra ZGC space is redundant.
Q2. Only aarch64, riscv and x86 allocate extra storage in the final stubs:
src/hotspot/cpu/aarch64/stubDeclarations_aarch64.hpp: do_arch_blob(final, 20000 ZGC_ONLY(+60000))
src/hotspot/cpu/riscv/stubDeclarations_riscv.hpp: do_arch_blob(final, 20000 ZGC_ONLY(+10000))
src/hotspot/cpu/x86/stubDeclarations_x86.hpp: do_arch_blob(final, 31000 WINDOWS_ONLY(+22000) ZGC_ONLY(+20000))
I believe the other ports generate less copy routines overall and/or share more of the generated code so the size disparity with the default (G1) case is not enough to require an additional allocation (the size of the ZGC barriers may also be smaller for these ports -- not sure).
src/hotspot/cpu/arm/stubDeclarations_arm.hpp: do_arch_blob(final, 22000)
src/hotspot/cpu/ppc/stubDeclarations_ppc.hpp: do_arch_blob(final, 24000)
src/hotspot/cpu/s390/stubDeclarations_s390.hpp: do_arch_blob(final, 20000)
Bottom line: it doesn't look like there is any more work to do.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25094#issuecomment-2858937162
More information about the hotspot-compiler-dev
mailing list