On Thu, Dec 4, 2014 at 5:36 PM, David Holmes <david.hol...@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.
