[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[Martin Buchholz]

On Thu, Dec 4, 2014 at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
> Martin,
>
> On 2/12/2014 6:46 AM, Martin Buchholz wrote:

> Is this finalized then? You can only make one commit per CR.

Right.  I'd like to commit and then perhaps do another round of clarifications.

> I still find this entire comment block to be misguided and misplaced:
>
> !     // Fences, also known as memory barriers, or membars.
> !     // See hotspot sources for more details:
> !     // orderAccess.hpp memnode.hpp unsafe.cpp
> !     //
> !     // One way of implementing Java language-level volatile variables
> using
> !     // fences (but there is often a better way without) is by:
> !     // translating a volatile store into the sequence:
> !     // - storeFence()
> !     // - relaxed store
> !     // - fullFence()
> !     // and translating a volatile load into the sequence:
> !     // - if (CPU_NOT_MULTIPLE_COPY_ATOMIC) fullFence()
> !     // - relaxed load
> !     // - loadFence()
> !     // The full fence on volatile stores ensures the memory model
> guarantee of
> !     // sequential consistency on most platforms.  On some platforms (ppc)
> we
> !     // need an additional full fence between volatile loads as well (see
> !     // hotspot's CPU_NOT_MULTIPLE_COPY_ATOMIC).

Even I think this comment is marginal - I will delete it.  But
consider this a plea for better documentation of the hotspot
internals.

> why do want this description here - it has no relevance to the API itself,
> nor to how volatiles are implemented in the VM. And as I said in the bug
> report CPU_NOT_MULTIPLE_COPY_ATOMIC exists only for platforms that want to
> implement IRIW (none of our platforms are multiple-copy-atomic, but only PPC
> sets this so that it employs IRIW).

I believe the comment _does_ reflect hotspot's current implementation
(entirely from exploring the sources).
I believe it's correct to say "all of the platforms are
multiple-copy-atomic except PPC".
I believe hotspot must implement IRIW correctly to fulfil the promise
of sequential consistency for standard Java, so on ppc volatile reads
get a full fence, which leads us back to the ppc pointer chasing
performance problem that started all of this.