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 <marti...@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.shipi...@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-inter...@cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
