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

[Martin Buchholz]

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 [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?

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.