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
