[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
martinrb at google.com
Thu Nov 27 02:21:40 UTC 2014
On Tue, 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.
Right - I've been groking that.
> The bit that always confuses me about release and acquire is ordering is restricted to one direction, as talked about in orderAccess.hpp . 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  (acting like a monitor exit). Is that contrary to C++ release fences where ordering is restricted both to prior and succeeding accesses? 
> So what about the following?
> a = r1; // Cannot move below the fence
> b = r2; // Can move above the fence?
I think the hotspot docs need to be more precise about when they're
talking about movement of stores and when about loads.
> // release. I.e., subsequent memory accesses may float above the
> // release, but prior ones may not float below it.
As I've said elsewhere, the above makes no sense without restricting
the type of access.
More information about the core-libs-dev