RFR(M): 8166970: Adapt mutex padding according to DEFAULT_CACHE_LINE_SIZE

[Doerr, Martin]

Hi David,

thanks for taking a look at my proposal.

Maybe "unnecessary cache line sharing of contended memory" would be more comprehensive.

The purpose of the padding is to avoid the following situation:
2 Monitor instances are located behind each other and some fields end up on the same cache line.
Some threads running on some processors compete for the first Monitor while some other threads running on some processors compete for the second one.
The cache line needs to get transferred between all involved processors.

If we add enough padding, the fields which are accessed by many processors end up on different cache lines. This splits the problem into 2 independent problems. The threads competing for the first Monitor don't interfere with those ones competing for the second one any more.

The existing padding implementation is not optimal. It's a little too small on some platforms. On other platforms, it is not wrong to pad more than necessary, but ideally, one would pad to make the Monitor size equal to the cache line size. I have kept the minimum of 64 because _name is not only used for padding and I guess people don't want it too short.

x86_64 and SPARC have DEFAULT_CACHE_LINE_SIZE=128 in typical configurations. That's like PPC64 so the change also improves the padding on these platforms as well.
(On x86_64 we get the same result as on PPC64: The length of _name gets extended from 64 to 72 in product build). The padding increase only gets huge on S390.

Best regards,
Martin


-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Donnerstag, 6. Oktober 2016 04:31
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8166970: Adapt mutex padding according to DEFAULT_CACHE_LINE_SIZE

On 1/10/2016 1:48 AM, Doerr, Martin wrote:
> Hi,
>
> the current implementation of Monitor padding (mutex.cpp) assumes that cache lines are 64 Bytes. There's a platform dependent define "DEFAULT_CACHE_LINE_SIZE" available which can be used. Purpose of padding is to avoid false sharing.
>
> My proposed change is here:
> http://cr.openjdk.java.net/~mdoerr/8166970_mutex_padding/webrev.00/

Not sure I understand the existing padding code. What false sharing are 
we trying to avoid?

And if the existing code assumes a cache line size of 64 and declares 
_name to be 64 chars, then why can't the new code declare name to be 
DEFAULT_CACHE_LINE_SIZE chars? This suggests the existing padding code 
is wrong (not just hard-wired).

Which platforms will this cause an actual change in Monitor size other 
than S390?

Thanks,
David

> Please review. If will also need a sponsor.
>
> Thanks and best regards,
> Martin
>