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

[Paul Sandoz]

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