JEP 193: Enhanced Volatiles (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Wed Mar 5 22:01:28 UTC 2014

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.

More information about the core-libs-dev mailing list