JEP 193: Enhanced Volatiles

[David M. Lloyd]

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?)
> [...and then...]
> 2.  Translation to bytecodes.  What bytecode should javac emit when it
> encounters an volatile accessor or atomic update?  We've identified a
> handful of candidates:
>
> 2a: new bytecodes.  This is the most direct and pure, but most intrusive
> (and least extensible), means of delivering on the promise of "it's time
> to move this stuff into the programming model proper."  The "wide"
> bytecode offers a means to express fenced variants of
> {get,put}{field,static} with only a single new bytecode, but this
> doesn't scale well to CAS (explosion of data types and data locations
> (static field, instance field, array element)), which is really the
> important case.

Somewhere between new bytecodes and field handles, perhaps a single 
bytecode could suffice - one which is similar to getfield except instead 
of reading the field, it pushes a virtual "object" on to the stack which 
can then only be operated upon by invokeinterface on the pertinent 
"VolatileXxx" interface and otherwise doesn't have a real "type" per se.

-- 
- DML