Draft JEP on enhanced volatiles

[Doug Lea]

Thanks Alex for looking this over!

On 02/10/2014 11:12 PM, Alex Buckley wrote:
>>
>> We then enable access to corresponding methods for (typically
>> volatile) fields using the ".volatile" prefix. For example:
>
> Only "typically" volatile? Surely, "necessarily" volatile.

This is a TBD issue. There are good rationales and
popular demand for applying uniformly to any field (or array
element). We hope but don't know that we can provide a
reasonable memory semantics for all cases. For present purposes,
nothing much depends on this though --  either some usages of .volatile
will be caught as illegal by static semantics, or they will be
translated in the same way as other cases.

>
> 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').

Yes, the intent is any field (or array) access expression.
I haven't checked against Java8 BNF (because I haven't seen
Java8 BNF), but in older versions, it seems that adding this
to the rhs of "Selector" production should work?

>
> 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?

Yes, thanks.

>
>> 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();

Definitely not that. x[0] here is a ref to an int[].
So you'd allow, for example,
   x[0].volatile.setRelaxed(new int[1]);
in the same cases that you'd allow:
   x[0] = new int[1];


> 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.
>

Yes. The form of semantics spec should be similar to that for
for-each expressions in terms of Iterable API, but with some
extra "as if" caginess.

-Doug