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

[Stefan Karlsson]

On Wed, 6 Dec 2023 23:05:14 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> > Sure. It think it is a good patch. However, given that you added this commment:
> > ```
> > // Hardware prefetchers on current implementations may pull 2 cache lines
> > // on access, therefore we pessimistically assume twice the cache line size
> > // for padding.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Do you have anything that backs up the claim that this is the case for "current implementations"? Maybe @sviswa7 can help answering if this is still the case for Intel hardware?
> 
> 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.

Thanks, Sandhya.

I think I found the statement that I was remembering:
https://mail.openjdk.org/pipermail/zgc-dev/2018-March/000184.html

>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.

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

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