RFR: 8237842: Separate definitions for default cache line and padding sizes

[Stefan Karlsson]

On Tue, 5 Dec 2023 11:23:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8321137](https://bugs.openjdk.org/browse/JDK-8321137) needs a clean separation between cache line sizes and padding sizes. At least on x86, there is a wrinkle with "assuming" the cache line size is 128 bytes to cater for prefetchers. Cleanly separating cache line size and padding size resolves this. I rewrote uses of `DEFAULT_CACHE_LINE_SIZE` in padding contexts to new macro.
> 
> The goal for this patch is to avoid actual values changes as much as possible. One of the changes come from cleaning up some of the old cases in x86 definition, thus simplifying the definition. I think the LP64 split is still useful there.
> 
> Additional testing:
>  - [x] Large build matrix of server/zero builds
>  - [x] Linux AArch64 server fastdebug, `tier{1,2}`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2}`

The *2 has been a contentious point for a long time. This is what I think happened:

In 'JDK-8049737: Contended Locking reorder and cache line bucket'

DEFAULT_CACHE_LINE was increased from 64 to 128. This was done for the ObjectMonitors, but it had an effect on other data structures in other parts of the JVM (Esp. in the GC). There were performance measurements done to try to see if the 64 to 128 change made any difference, but AFAIK, no performance difference could be seen, but the *2 change was left in place anyways.

And then 'JDK-8235931: add OM_CACHE_LINE_SIZE and use smaller size on SPARCv9 and X64' came along and changed the ObjectMonitor code to use its own define without the *2 but leaving the DEFAULT_CACHE_LINE_SIZE and padding code to still use *2!

We have asked Intel if really should be padding with two cache lines as we say here:

// Hardware prefetchers on current implementations may pull 2 cache lines
// on access, therefore we pessimistically assume twice the cache line size
// for padding.
#define DEFAULT_PADDING_SIZE (DEFAULT_CACHE_LINE_SIZE*2)


and their answer was that their hardware stopped doing that over 10 years ago (this question was asked a few years ago).

For ZGC we tried to poke at his a bit but gave up and added our own:

const size_t ZPlatformCacheLineSize    = 64;


So, with all that said. Do we really need to keep this *2 in the x64 code?

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

PR Comment: https://git.openjdk.org/jdk/pull/16973#issuecomment-1842484452