JEP 193: Enhanced Volatiles
David M. Lloyd
david.lloyd at redhat.com
Wed Mar 5 20:37:17 UTC 2014
On 03/03/2014 04:25 PM, Brian Goetz wrote:
>> Posted: http://openjdk.java.net/jeps/193
> Some follow-up thoughts on teasing apart the issues covered by this JEP.
> There are three main layers of questions to answer:
> 1. How do we surface the various pieces of this into the programming
> model? This includes language syntax (e.g.,
> x.volatile.compareAndSet()), library surface (e.g., the fictitious and
> not-terribly-satisfying VolatileInt interface), and relevant
> restrictions (e.g., can we do volatile operations on non-volatile fields
> or array elements?)
Also, relatedly, how far is this taken? It is easy to imagine
operations of this sort on reference fields and fields of all 8
primitive types, as well as arrays of all 8 primitive types, and object
arrays (which would of course cover all arrays-of-arrays as well).
Following the interface idea, you would need (at a maximum) one
interface type for each primitive type and one interface type for
Objects. Arrays should be able to reuse the same interface type since
array element types are constrained to the same set of possible types as
fields (though without an actual volatile qualifier of course).
So 9 interface types at maximum. At minimum, just having interfaces for
ints, longs, and Objects would match what is presently defined in
j.u.c.atomic, so 3 seems to be the low end.
Personally I think it would be nicest to support all 8, but I expect
there were probably good reasons (I'm guessing relating to false
sharing) that we don't have AtomicBooleanArrays and so forth.
Other random thought, the proposed .volatile syntax possibilities are a
little funny (even by the standards of the base strangeness of the
// one of these I guess?
int foo = ...;
int x = foo.volatile.compareAndSet(10, 15); // this one, I suppose?
int x = foo.volatile.compareAndSet(10, 15);
If .volatile is treated as a postfix unary operator which operates on
the left-hand term (what precedence I wonder? probably pretty high),
then the first option makes the most sense and aligns well with
"[objectexpression.]foo.volatile..." where "foo" is a field.
More information about the core-libs-dev