aarch64: Rationalize DEFAULT_PADDING_SIZE with ContendedPaddingWidth

Peter Kessler OS peter.kessler at os.amperecomputing.com
Tue Mar 18 23:58:39 UTC 2025


DEFAULT_PADDING_SIZE specifies the padding that should be put before a C++ field to avoid false sharing.  For aarch64 it is currently set to the size of a cache line.[1]  For aarch64 the size of a cache is defined to be 64 bytes.[2]

Similarly, ContendedPaddingWidth specifies the padding that should be put before a Java field to avoid false sharing.  For all platforms that is set to 128 bytes, but it can be changed from the java command line.[3]

aarch64 has the same potential interaction with pre-fetchers as described for the x86.[4]  That is, a pre-fetcher may fetch the _next cache line_ after a requested address.  If that next cache line contains the contended field, then the core that wants to atomically update the field needs to (re)negotiate for exclusive access to the cache line with the field.  Padding a contended field into _two_ cache lines avoids this false sharing.

I would like to rationalize the padding for aarch64 C++ fields with the padding for Java fields.  The change is easy: double the size of DEFAULT_PADDING_SIZE in globalDefinitions_aarch64.hpp.  But I am curious why the difference exists for aarch64 and not for x86, and if there implications that should be considered before submitting a pull request.  Increasing the padding will make C++ data structures with padded fields take more space, possibly causing more page faults, etc.   But avoiding false sharing may improve the performance of C++ atomic operations, lowering latency in places where it might be important.

I have built jdk-25+14 with DEFAULT_PADDING_SIZE defined as 128, and things work.[5]  I am unable to show significant performance changes.  Can someone recommend tests where false sharing of C++ fields in the JVM might a difference?  Or can I submit a pull request just because it seems silly to have different padding for C++ fields and Java fields on aarch64?

                                                ... peter

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L49
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L46
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L813
[4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/globalDefinitions_x86.hpp#L46
[5] I also tried various other sizes of DEFAULT_PADDING_SIZE.  I can report that some uses of padded fields are prepared for DEFAULT_PADDING_SIZE to be 0, but some uses result in compilation errors because they do not use the lovely templates that protect against 0-length C++ arrays.[6]
[6] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/padded.hpp#L67
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250318/cb7c37a5/attachment-0001.htm>


More information about the hotspot-runtime-dev mailing list