[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
martinrb at google.com
Fri Dec 5 21:29:44 UTC 2014
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
> 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
> ! // 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)
> ! // 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
> 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.
More information about the core-libs-dev