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

[Andrew Haley]

On 9/9/19 11:37 AM, Doerr, Martin wrote:

> 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.

So please say so, otherwise this comment is just baffling. I suggest either a
pointer to some discussion, or

"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."

[Credit: Doug Lea,
http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011966.html]

-- 
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