RFR: 8356774: AArch64: StubGen final stubs buffer too small for ZGC on Cavium CPU

[Andrew Dinn]

On Tue, 13 May 2025 08:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am a bit confused: does the same logic we used in [JDK-8356085](https://bugs.openjdk.org/browse/JDK-8356085) [fix](https://github.com/openjdk/jdk/commit/daf6fa1e6153d3fdf48ef0840790794e57349c38) applies here as well? E.g. should this final stub size even depend on ZGC build-time presence at all?

Before cleanup different arches used to generate memory copy stubs in either the compiler or final blobs but it was not uniform. After cleanup all arches generate them in the final blob. So, this has necessitated two different adjustments:

1) The fix for JDK-8356085 removed ZGC-specific space from the compiler blob size and moved it to the default allocation. There was no need for a special ZGC increment because none of the stubs include code generated by the barrier-set assembler. However, building with ZGC excluded revealed that the default allocation was too small for the normal requirement and only worked because of ZGC-derived slop. So, rather than remove the ZGC allocation it was added to the default.

2) This PR addresses insufficient storage for copy stubs i.e. changes the final blob size. It does not need to change the default allocation since that is sufficient for a build without ZGC on any HW, including Cavium ThunderX (you can verify that if you run a build that does include ZGC and specify -Xlog:stubs -XX:-UseZGC). The problem is that the extra space added to cater for ZGC is big enough on most hardware but not on ThunderX. That's because the array copy routines on ThunderX include code to handle unaligned copies which other arches do not inject. With ZGC enabled this means a lot more barrier code which blows the extra ZGX-allocated budget.

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

PR Comment: https://git.openjdk.org/jdk/pull/25203#issuecomment-2875681919