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

[DT]

I see time to time comments in the jvm sources referencing membars and fences. Would you say that they are used interchangeably ? Having the same meaning but for different CPU arch.

Sent from my iPhone

> On Nov 25, 2014, at 6:04 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Martin,
> 
> Thanks for looking into this.
> 
> 1141      * Currently hotspot's implementation of a Java language-level volatile
> 1142      * store has the same effect as a storeFence followed by a relaxed store,
> 1143      * although that may be a little stronger than needed.
> 
> IIUC to emulate hotpot's volatile store you will need to say that a fullFence immediately follows the relaxed store.
> 
> The bit that always confuses me about release and acquire is ordering is restricted to one direction, as talked about in orderAccess.hpp [1]. So for a release, accesses prior to the release cannot move below it, but accesses succeeding the release can move above it. And that seems to apply to Unsafe.storeFence [2] (acting like a monitor exit). Is that contrary to C++ release fences where ordering is restricted both to prior and succeeding accesses? [3]
> 
> So what about the following?
> 
>  a = r1; // Cannot move below the fence
>  Unsafe.storeFence();
>  b = r2; // Can move above the fence?
> 
> Paul.
> 
> [1] In orderAccess.hpp
> // Execution by a processor of release makes the effect of all memory
> // accesses issued by it previous to the release visible to all
> // processors *before* the release completes.  The effect of subsequent
> // memory accesses issued by it *may* be made visible *before* the
> // release.  I.e., subsequent memory accesses may float above the
> // release, but prior ones may not float below it.
> 
> [2] In memnode.hpp
> // "Release" - no earlier ref can move after (but later refs can move
> // up, like a speculative pipelined cache-hitting Load).  Requires
> // multi-cpu visibility.  Inserted independent of any store, as required
> // for intrinsic sun.misc.Unsafe.storeFence().
> class StoreFenceNode: public MemBarNode {
> public:
>  StoreFenceNode(Compile* C, int alias_idx, Node* precedent)
>    : MemBarNode(C, alias_idx, precedent) {}
>  virtual int Opcode() const;
> };
> 
> [3] http://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/
> 
>> On Nov 25, 2014, at 1:47 AM, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> OK, I worked in some wording for comparison with volatiles.
>> I believe you when you say that the semantics of the corresponding C++
>> fences are slightly different, but it's rather subtle - can we say
>> anything more than "closely related to"?
>> 
>> On Mon, Nov 24, 2014 at 1:29 PM, Aleksey Shipilev
>> <aleksey.shipilev at oracle.com> wrote:
>>> Hi Martin,
>>> 
>>>> On 11/24/2014 11:56 PM, Martin Buchholz wrote:
>>>> Review carefully - I am trying to learn about fences by explaining them!
>>>> I have borrowed some wording from my reviewers!
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8065804
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/
>>> 
>>> I think "implies the effect of C++11" is too strong wording. "related"
>>> might be more appropriate.
>>> 
>>> See also comments here for connection with "volatiles":
>>> https://bugs.openjdk.java.net/browse/JDK-8038978
>>> 
>>> Take note the Hans' correction that fences generally imply more than
>>> volatile load/store, but since you are listing the related things in the
>>> docs, I think the "native" Java example is good to have.
>>> 
>>> -Aleksey.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest