[jmm-dev] jdk9 APIs [Fences specifically]

[Doug Lea]

On 08/14/2015 02:36 PM, Hans Boehm wrote:
> On Fri, Aug 14, 2015 at 4:50 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>  > So there are limitations in the ability of ordering control to
>  > improve responsiveness. Which is unsurprising given all the
>  > other limitations under weak scheduling guarantees. But
>  > that's not much of an argument for not even allowing it.
> I think it's not a limitation; it's just the wrong mechanism.
> The mechanism you want doesn't care about reordering of
> memory visibility to other threads.  That's what fences are

I suppose we should stop arguing about terminology/domains but ...
Ensuring that the writes are not reordered (as seen
by other threads) seems to be a prerequisite in all the
cases under consideration here. So at least some of us
conclude that solutions should build off this (fence) constraint.

> As you point out, that's kind of the domain of C-style volatiles,
> though they really only address the "combining" part.

The use of (C) volatile casts amounts to telling the compiler:
"I cannot tell you why to write/read this variable; just
do it".  If that's the best available solution, in Java, we could
add analogous VarHandle methods of the form:
   void setOpaquely(Object owner, T x);
   T getOpaquely(Object owner);

I don't like this at all. But to defend anyway: they do form a
sort of matched set with the reachabilityFence
implementation as "useOpaquely(ref)". And hotspot has an
analogous internal (misnamed) construct MemBarCPUOrder that means:
"I cannot tell you why not to reorder these IR nodes; just don't".
This would come into play in the implementation of these methods
as the "solution"  to the lack of explicit storeStore fence.
So this is entirely workable even if entirely unappealing.

>  >
>  > But even if so, it seems better to have a uniform API:
>  >   writes:  full > release > storeStore
>  >   reads:   full > acquire > loadLoad
>  > even if loadLoad is internally mapped to acquire.
>  > And omitting it feels even more wrong if we support
>  > RCU-like usages with scoped loadLoadFence(Object ref).
>
> C++ has a great solution to that: include neither storeStore
> nor loadLoad.

Some history: In jdk8, after a similar discussion, we added only
the three C++ fences as internal Unsafe intrinsics (which in turn
map to existing MemBar IR nodes inside hotspot). But some JVM
engineers voted with their feet about these: They introduced
internal storeStore so they could use it (and/or directly
generate) instead of release when applicable. The fact that
it is cheaper or no more expensive than alternatives on most if not
all ARM processors is surely the main reason for use. But
other use cases are not just motivated by cost.

It would be nice to avoid similar problems with jdk9 public APIs.
(This accounts for my choice of words in initial post
that it "seems wise" to include them.)

> AFAICT, storeStore is a feature we don't know how to specify,

Again, the spec is conceptually easy: Of all the ordering
effects allowed by the base memory model rules, disable
the indicated case of store-store reordering.

The hard part is specifying the conditions under which usage
does what any given programmer expects. Moreso than other fences.
But this does not seem to be a good enough reason to omit from API.

-Doug