JEP 193: Enhanced Volatiles

[David M. Lloyd]

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

It could even be a *real* object if it were possible to rely on some 
form of escape analysis to optimize it in the majority of cases, and if 
the puzzle of allocation/caching/storing the object could be solved, 
though the memory usage story in the non-escape case would have to be 
pretty buttoned down to make this acceptable IMO.
-- 
- DML