Draft JEP on enhanced volatiles

[Brian Goetz]

It's about time we brought atomic ops out of the shadows of Unsafe and 
into the programming model proper!  It was a good compromise ten years 
ago to stuff these into Unsafe, but its time for these features to grow 
up.

Specific to this proposal, I like how the VolatileXxx interface approach 
allows us to add new fencing modes and/or atomic operations should we 
discover that the initial set is deficient.  I also like how this 
potentially gives us a consistent story for volatile semantics on array 
elements.

I can see a clean and straightforward implementation here at all the 
required touch points: language spec, memory model, type system, 
compiler, and VM runtime, and none of them require any special magic. 
(Having spent some time exploring this design space myself, I think the 
proposed surfacing is the least objectionable and most transparent of 
the options that I've seen.)

Minor nits called out inline.

Otherwise, Reviewed (as JDK reviewer) and Endorsed (as area lead).

> We then enable access to corresponding methods for (typically
> volatile) fields using the ".volatile" prefix. For example:

Is this a prefix or a suffix?

> The ".volatile" syntax is slightly unusual, but we are confident that
> it is syntactically unambiguous and semantically specifiable.

And, it is reasonably consistent with other similar uses of keywords for 
qualifying access to functionality, such as I.super or Outer.this.

> We also expect to allow volatile
> operations on array elements in addition to fields.

This calls for the memory model to provide clear semantics for mixed 
accesses, such as volatile write / nonvolatile read.  (The same would be 
true if we permitted the use of the .volatile modifier on nonvolatile 
fields.)
> Several other alternatives
> (including those based on field references) have been raised and
> dismissed as unworkable on syntactic, efficiency, and/or usability
> grounds

or extensibility grounds.  Many existing proposals might work for the 
operations in front of us today, but not scale as new fencing modes or 
atomic operations are discovered.

> Risks and Assumptions
> ---------------------
>
> We are confident of feasibility.  However, we expect that it will
> require more experimentation to arrive at compilation techniques that
> result in efficient enough implementation for routine use in the
> performance-critical contexts where these constructs are most often
> needed. The use of method handles may be impacted by and may impact
> JVM method handle support.

As a limitation, I'd call out that its not obvious how this would scale 
to DCAS.

> A large number of usages in java.util.concurrent (and a few elsewhere
> in JDK) could be simplified and updated to use this support.

Hooray!