Draft JEP on enhanced volatiles
dl at cs.oswego.edu
Tue Feb 11 12:37:11 PST 2014
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?
>> 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.volatile.setAllToNull();
Definitely not that. x here is a ref to an int.
So you'd allow, for example,
in the same cases that you'd allow:
x = new int;
> 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.
More information about the compiler-dev