jdk9 VarHandle and Fence methods

[Doug Lea]

On 08/21/2015 10:50 AM, Gil Tene wrote:

> Specifically:
>
> - How should one use Fences.storeStoreFence() (and/or other methods) to
> achieve the equivalent of an Atomic*.lazyset()?

First: lazySet was among the worst names ever, although the internal
name putOrderedX comes close. So this is more confusing than it should be.

AtomicX.lazySet will become a synonym for setRelease, and compatible
with C/C++11 memory_order_release stores. You can also
get essentially the same effect using a preceding releaseFence.
In turn releaseFence maps into the current hotspot MemBarRelease,
accessible (for now) via Unsafe.storeFence. It is stronger than
hotspot MemBarStoreStore (that will also be exported) because
releaseFence includes a LoadStore. You almost always want
releaseFence. The range of sane applicability of storeStoreFence
is small, and it might not even be included except that there are
processors (including ARM) for which it is generally cheaper
when it applies.

> - Is NotReallyVarHandle.setOpaque() more relaxed than a lazySet()? Or is it
> similar?

The unloved-but-necessary method setOpaque is setRelaxed with what
amounts to a compiler directive saying that the write must actually
occur even if other JMM rules would allow it to be optimized away.
Usage should be rare. Think IO.

> BTW, my understanding of the current lazySet() implementation is that it
> guarantees a store-store fence preceding the lazy store (but does not
> guarantee one after the operation). In implementation (e.g. in HotSpot) it
> appears to provide a store-store both before and after the operation (but I
> don't thin that this can be assumed to be guaranteed).

setRelease/lazySet/putOrderedX does not require a trailing fence.
Compilers may impose an internal reordering fence for internal reasons.

-Doug