JEP 193: Enhanced Volatiles

[David M. Lloyd]

On 03/03/2014 04:53 PM, David M. Lloyd wrote:
> 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.

I suppose you'd also need a second bytecode for doing the same thing 
with array elements like *aload, if that branch of this idea is pursued.

-- 
- DML