RFR(XXS): 8235931: add OM_CACHE_LINE_SIZE and use smaller size on SPARCv9 and X64

David Holmes david.holmes at oracle.com
Wed Dec 18 05:50:03 UTC 2019


Hi Dan,

On 18/12/2019 7:34 am, Daniel D. Daugherty wrote:
> Greetings,
> 
> I'm extracting another standalone fix from the Async Monitor Deflation
> project (JDK-8153224) and sending it out for review (and testing)
> separately. This is an XXS sized fix, but since it involves cache
> line sizes I don't think a trivial review is appropriate.

Can you elaborate on why a smaller cache-line-size assumption is 
beneficial here? Do you have performance numbers for the bug report?

Otherwise the mechanics of the change look fine, except I would suggest 
that this:

#ifndef OM_CACHE_LINE_SIZE
// Use DEFAULT_CACHE_LINE_SIZE if not already specified for
// the current build platform.
#define OM_CACHE_LINE_SIZE DEFAULT_CACHE_LINE_SIZE
#endif

should go in the shared globalDefinitions.hpp file.

Thanks,
David
-----

>      JDK-8235931 add OM_CACHE_LINE_SIZE and use smaller size on SPARCv9 
> and X64
>      https://bugs.openjdk.java.net/browse/JDK-8235931
> 
> Here's the webrev URL:
> 
>      http://cr.openjdk.java.net/~dcubed/8235931-webrev/0-for-jdk15/
> 
> Folks that have reviewed JDK-8153224 will recognize these changes as
> a subset of the cache line changes from the Async Monitor Deflation
> project. It's a subset because there are more fields that need to be
> on separate cache lines in the Async Monitor Deflation project.
> 
> These changes are being tested in a Mach5 Tier[1-3] run that's still
> running (JDK14 ATR has priority). I've also run these changes thru
> a set of 10 SPECjbb2015 runs; I'm waiting for my various SPECjbb2015
> runs to finish so I can do the analysis.
> 
> Thanks, in advance, for comments, questions or suggestions.
> 
> Dan


More information about the hotspot-runtime-dev mailing list