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

[Stefan Karlsson]

On Wed, 6 Dec 2023 10:06:40 GMT, Aleksey Shipilev <shade 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"?
> 
> I was merely trying to explain why `*2` is even there. The common explanation is referring to a "common wisdom" about adjacent cache line prefetchers. Granted, that might have been true only a decade ago, and it might not hold true anymore. I can change "current" to "some" or "some old" if you think that is more neutral.
> 
> Again, I don't think this PR should be discussing `*2` thing. It should be a separate deep dive and clear few-liner change later. That reminds me we would probably change the default for `ContendedPaddingWidth`, probably by tying it to `DEFAULT_PADDING_SIZE` once this lands. We should not be doing it here, though, because it would have footprint implications on platforms with large cache lines, like S390X.

Well I bring this up because you are adding a comment that further sediments the understanding of the need to use *2. As I said I think the patch looks good and I'm just taking the opportunity to talk about this now that someone is yet again juggling around this *2 value. Changing to "some" is probably a good idea.

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

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