[jmm-dev] jdk9 APIs

[Paul E. McKenney]

On Tue, Aug 11, 2015 at 03:11:10PM -0400, Doug Lea wrote:
> On 08/11/2015 02:01 PM, Jeremy Manson wrote:
> >Just curious: which end users are jonesing for a Fences API?  I talk with a LOT
> >of Java users, and it's *never* come up outside of the kinds of people on this list.
> >
> 
> Good timing. I was about to post this set of misc follow-up notes
> that mentions this.
> 
> * I don't want to get overly consumed about analogs of consume mode,
> but it would be nice to deal with it in a way that is good enough not
> to demand follow-up efforts. A different approach than getDependently
> is to add an overloaded loadLoadFence method that restricts its scope
> to loads from the given reference: void loadLoadFence(Object ref).
> This is similar to the approach used in a previous (scrapped) version
> of Fence APIs. JVMs could just equate it (as well as the no-arg
> version) to acquireFence, but with some effort it could be implemented
> to get better performance on some platforms. At the moment, this seems
> like a better approach to me than VarHandle getDependently methods.

Well, if you change your mind about being consumed by analogs of consume,
please see the attached revision of C++ working draft N4321.  ;-)

The most recent addition is what can be thought of as a defacto
characterization of current compiler behavior in conjunction with actual
Linux-kernel usage.  This addition is in Section 7.9 starting on page 28.
Prior to Section 7.9, there are a number of other proposals involving
adding additional marking to the dependency chains.  Section 7.10
starting on page 34 gives a draft evaluation of the various proposals,
see especially Table 1 on page 35.

Within the Linux kernel, dependency-chain heads are marked with one of
the variants of rcu_dereference(), which has acquire-like semantics,
so that rcu_dereference()'s load of the pointer is ordered against both
loads and stores that are part of the dependency chain headed by that
rcu_dereference().  For a fanciful example:

	p = rcu_dereference(gp);
	if (!p->visited) /* Don't unnecessarily dirty the cache. */
		p->visited = 1;

Here the assignment to p->visited is ordered after the load from gp.

> * VarHandles serve two roles: (1) providing access to CAS instructions
> (plus the special RMW variants getAndAdd etc) that have no bytecodes
> (2) supporting moded load/store access that in principle is the same
> as people could arrange with the idiomatic application of Fences, but
> in practice possibly different because JVMs might have an easier time
> selecting instructions that combine fencing and access.
> 
> * The Fence API is geekier than VarHandles but no less necessary as
> Unsafe goes away.  One audience is a small number of expert concurrent
> programmers writing performance-sensitive code. As a general
> observation, the more that such people understand their concurrent
> algorithms, the more flexibility they need to implement them.  There
> are a few constructions inside java.util.concurrent relying on them
> (for example in StampedLock) that cannot otherwise be obtained in any
> reasonable way. Which would be a problem without Fence API when
> Unsafe goes away.
> 
> Another (mostly future) audience is Tool developers. Efforts to obtain
> desired consistency properties via tool-based fence placements are
> starting to approach plausibility. (Including a nice upcoming OOPSLA
> paper "Declarative fence insertion" by Bender, Lesani, and Palsberg
> that I don't see anywhere online yet.) We'd rather not see Java ruled
> out of such efforts just because of the lack of access to
> functionality that must exist in any Java implementation.
> 
> (Gratuitous aside: Fences are just flexible Semicolons.  Plain
> semicolons outlived their usefulness, as bemoaned in the fun read:
> "The Silently Shifting Semicolon"
> http://snapl.org/2015/abstracts/full/Marino.html
> http://www.cs.ucla.edu/~todd/research/snapl15.pdf)

I do like this view of the matter!  Which probably means that everyone
else hates it.  ;-)

							Thanx, Paul