Draft JEP on enhanced volatiles

[Alex Buckley]

Hi Doug,

On 2/7/2014 10:38 AM, Doug Lea wrote:
> We model the extended operations on volatile integers via an interface
> VolatileInt, that also captures the functionality of AtomicInteger
> (which will also be updated to reflect Java Memory Model revisions as
> part of this JEP). A tentative version is below. Similar interfaces
> are needed for other primitive and reference types.
>
> We then enable access to corresponding methods for (typically
> volatile) fields using the ".volatile" prefix. For example:

Only "typically" volatile? Surely, "necessarily" volatile.

>      class Usage {
>          volatile int count;
>          int incrementCount() {
>              return count.volatile.incrementAndGet();
>          }
>      }
>
> The ".volatile" syntax is slightly unusual, but we are confident that
> it is syntactically unambiguous and semantically specifiable.  New
> syntax is required to avoid ambiguities with existing usages,
> especially for volatile references -- invocations of methods on the
> reference versus the referent would be indistinguishable.  The
> ".volatile" prefix introduces a scope for operations on these
> "L-values", not their retrieved contents.  However, just using the
> prefix itself without a method invocation (as in "count.volatile;")
> would be meaningless and illegal.

I presume the term before '.volatile' is not limited to an expression 
name ('count', 'this.count', 'x.f.count'); it could also be a field 
access expression ('new Outer().new Usage().count').

Note there is one field in the language which cannot be the term before 
'.volatile': the length field of an array object. Being final, it is 
necessarily not volatile, and '.volatile' only works for volatile 
fields, right?

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

Only array elements, or array components in general? Given:

   volatile int[][] x = ...

is it meaningful to say:

   return x[0].volatile.setAllToNull();

or somesuch? In other words, is there an interface VolatileArray? (So 
Jeremy would have to update 
http://jeremymanson.blogspot.com/2009/06/volatile-arrays-in-java.html...)

> The main task is to translate these calls into corresponding JVM
> intrinsics. The most likely option is for the source compiler to use
> method handles. This and other techniques are known to suffice, but
> are subject to further exploration. Minor enhancements to intrinsics
> and a few additional JDK library methods may also be needed.

The JLS doesn't know what a JVM intrinsic is (and nor does the JVMS), so 
the meaning of count.volatile.X() must be specified by appeal to ("as if 
by ...") an invocation of the X() method on some synthesized receiver.

Alex