RFR(XS): 8230434: [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently

[Doerr, Martin]

Hi Andrew,

the Aarch64 implementation is not affected by this problem.
"support_IRIW_for_not_multiple_copy_atomic_cpu" is false, so C1 and C2 compilers add fences after volatile stores.
Having this fences makes the additional release barrier redundant wrt. publishing volatile fields.

There's already an open issue "Define AArch64 as MULTI_COPY_ATOMIC":
https://bugs.openjdk.java.net/browse/JDK-8230392
Currently, doing that only optimizes out the additional fence from the taskqueue. But it may be relevant for future changes.

Arm 32 is a different topic. I guess supporting IRIW is not planned. Otherwise, the platform specific parts will need to get implemented. Shared code is ready.

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Mittwoch, 11. September 2019 11:14
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: RFR(XS): 8230434: [C1, C2] Release barrier for volatile field stores
> in constructors implemented inconsistently
> 
> On 9/11/19 9:35 AM, Andrew Haley wrote:
> 
> > "Programmers do not expect that even though final fields are
> > specifically publication-safe, volatile fields are not always
> > so. For various implementation reasons, most JVMs arrange that
> > volatile fields are publication safe anyway. We do the same here to
> > avoid surprises."
> 
> Hmm, and, thinking some more, I wonder if AArch64 needs this too. It
> probably does, because even though AArch64 is (sort of) multi-copy
> atomic I don't think there's anything to disallow a plain store from
> floating above a volatile store. Having said that, we've never
> observed any failures, but perhaps that's because implementations of
> AArch64 are stronger than the spec requires.
> 
> Thank you for raising this issue.  :-)
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671