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

[Doerr, Martin]

Hi Andrew,

we had discussed that a long time ago:
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-November/001334.html

Even though the Java memory model doesn't strictly require this, we still believe the behavior would be unexpected for many Java programmers.
Assume you create a new AtomicInteger(1). Would you expect the value 0 to be observable by another thread?
This behavior would only show up on PPC64 without this addition. Since the performance impact is not significant, we had decided to avoid it.

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Montag, 9. September 2019 10:16
> 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
> 
> +  // 3. On processors which are not CPU_MULTI_COPY_ATOMIC (e.g.
> PPC64),
> +  //    support_IRIW_for_not_multiple_copy_atomic_cpu selects that
> +  //    MemBarVolatile is used before volatile load instead of after volatile
> +  //    store, so there's no barrier after the store.
> +  //    We want to guarantee the same behavior as on platforms with total
> store
> +  //    order, although this is not required by the Java memory model.
> 
> Why?
> 
> --
> 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