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

[David Holmes]

Martin,

On 2/12/2014 6:46 AM, Martin Buchholz wrote:
> David, Paul (i.e. Reviewers) and Doug,
>
> I'd like to commit corrections so we make progress.

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

> I think the current webrev is simple progress with the exception of my
> attempt to translate volatiles into fences, which is marginal (but was
> a good learning exercise for me).

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

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

David