Current padding code pessimistically assumes that we need to pad for twice the cache line size to avoid false sharing on x86. One example usually given is adjacent cache line hardware prefetchers that read *two* cache lines on every access, thus extending the false sharing window. This was a common wisdom for many years, but it might not be true anymore.

We need to check if this is still true for current hardware implementations, and if not, relax padding size to 64 bytes. This would improve footprint for currently padded data structures in Hotspot.

Stefan mentions during JDK-8237842 review that Intel implementations seem to be immune to this issue for a while:
"We have asked Intel if really should be padding with two cache lines as we say here: [code] ... and their answer was that their hardware stopped doing that over 10 years ago (this question was asked a few years ago).
https://github.com/openjdk/jdk/pull/16973#issuecomment-1842484452

Sandhya says:
"From my understanding:
Padding to 64 byte is needed to avoid cache line false sharing.
Padding to 256 byte is recommended for heavily accessed contended data to avoid false sharing induced by prefetchers.
Padding to 128 byte may be sufficient for general contended data."
https://github.com/openjdk/jdk/pull/16973#issuecomment-1843830251

Hugh mentions:
"FWIW, adjacent cache line prefetching is usually enabled for clients (desktops, laptops) and disabled for servers. It has been this way for a long time. For servers, the bandwidth penalty of adjacent cache line prefetching was likely the determining factor in this difference."
https://mail.openjdk.org/pipermail/zgc-dev/2018-March/000184.html

JDK-8237842 allows us to decide the padding size separately from cache line size.