On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193Some 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
