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
