Draft JEP on enhanced volatiles

[Noctarius]

Hey Doug,

The syntax is definitely weird and unusual but from users point I
think I could live with that :)

Thanks for this proposal, absolutely something we were waiting for.

Chris

Am 07.02.2014 19:36, schrieb Doug Lea:
> 
> [To core-libs-dev; separately cross-posted to hotspot-dev and 
> compiler-dev.]
> 
> Now that the JMM update project is live (see
> http://openjdk.java.net/projects/jmm/), it would be helpful to
> get some preliminary feedback on one of its sure-to-be-needed
> counterparts: finally supporting a reasonable way to express
> atomic and/or ordered access operations beyond
> volatile-read/write. Some of you might know that the lack of
> these has often been discusses as a source of frustration and
> problems. One reason for nopt dealing with it sooner is the
> lack of a basis for even specifying such things, to be fixed
> with JMM update. But we also need some way for people to
> express them. The only good means for doing so appear to
> require a small amount of syntax support. Most people who have
> seen it seem to agree that the ".volatile" proposal below is
> the approach most likely to succeed. (We've considered a lot of
> others.) I'm hoping that members of libs, hotspot, and compiler
> groups can give it a sanity check before submitting (hopefully
> in a week or so). Thanks!
> 
> Draft JEP proposal Title: Enhanced Volatiles Author: Doug Lea 
> [...other metadata elided for now...]
> 
> 
> Summary -------
> 
> This JEP results in a means for programmers to invoke the
> equivalents of java.util.concurrent.atomic methods on volatile
> fields.
> 
> Motivation ----------
> 
> As concurrent and parallel programming in Java continue to
> expand, programmers are increasingly frustrated by not being
> able to use Java constructions for arranging atomic operations
> for the fields of individual classes; for example atomically
> incrementing a "count" field. Until now the only ways to
> achieve these effects were to use a stand-alone AtomicInteger
> (adding both space overhead and additional concurrency issues
> to manage indirection) or, in some situations, to use atomic
> FieldUpdates (often encountering more overhead than the 
> operation itself), or to use JVM Unsafe intrinsics. Because
> intrinsics are preferable on performance grounds, their use has
> been increasingly common, to the detriment of safety and
> portability. Without this JEP, these problems are expected to
> become worse as atomic APIs expand to cover additional access
> consistency policies (aligned with the recent C++11 memory
> model) as part of Java Memory Model revisions.
> 
> Description -----------
> 
> The target solution requires a syntax enhancement, a few 
> library enhancements, and compiler support.
> 
> We model the extended operations on volatile integers via an
> interface VolatileInt, that also captures the functionality of
> AtomicInteger (which will also be updated to reflect Java
> Memory Model revisions as part of this JEP). A tentative
> version is below. Similar interfaces are needed for other
> primitive and reference types.
> 
> We then enable access to corresponding methods for (typically 
> volatile) fields using the ".volatile" prefix. For example:
> 
> class Usage { volatile int count; int incrementCount() { return
> count.volatile.incrementAndGet(); } }
> 
> The ".volatile" syntax is slightly unusual, but we are
> confident that it is syntactically unambiguous and semantically
> specifiable.  New syntax is required to avoid ambiguities with
> existing usages, especially for volatile references --
> invocations of methods on the reference versus the referent
> would be indistinguishable.  The ".volatile" prefix introduces
> a scope for operations on these "L-values", not their retrieved
> contents.  However, just using the prefix itself without a
> method invocation (as in "count.volatile;") would be
> meaningless and illegal.  We also expect to allow volatile 
> operations on array elements in addition to fields.
> 
> The main task is to translate these calls into corresponding
> JVM intrinsics. The most likely option is for the source
> compiler to use method handles. This and other techniques are
> known to suffice, but are subject to further exploration. Minor
> enhancements to intrinsics and a few additional JDK library
> methods may also be needed.
> 
> Here is a tentative VolatileInt interface.  Those for other
> types are similar.  The final released versions will surely
> differ in small ways.
> 
> interface VolatileInt { int get(); int getRelaxed(); int
> getAcquire(); int getSequential();
> 
> void set(int x); void setRelaxed(int x); void setRelease(int
> x); void setSequential(int x);
> 
> int getAndSet(int x); boolean compareAndSet(int e, int x); 
> boolean compareAndSetAcquire(int e, int x); boolean
> compareAndSetRelease(int e, int x); boolean
> weakCompareAndSet(int e, int x); boolean
> weakCompareAndSetAcquire(int e, int x); boolean
> weakCompareAndSetRelease(int e, int x);
> 
> int getAndAdd(int x); int addAndGet(int x); int
> getAndIncrement(); int incrementAndGet(); int
> getAndDecrement(); int decrementAndGet(); }
> 
> 
> Alternatives ------------
> 
> We considered instead introducing new forms of "value type"
> that support volatile operations. However, this would be
> inconsistent with properties of other types, and would also
> require more effort for programmers to use. We also considered
> expanding reliance on java.util.concurrent.atomic
> FieldUpdaters, but their dynamic overhead and usage limitations
> make them unsuitable. Several other alternatives (including
> those based on field references) have been raised and dismissed
> as unworkable on syntactic, efficiency, and/or usability 
> grounds over the many years that these issues has been
> discussed.
> 
> 
> Risks and Assumptions ---------------------
> 
> We are confident of feasibility.  However, we expect that it
> will require more experimentation to arrive at compilation
> techniques that result in efficient enough implementation for
> routine use in the performance-critical contexts where these
> constructs are most often needed. The use of method handles may
> be impacted by and may impact JVM method handle support.
> 
> Impact ------
> 
> A large number of usages in java.util.concurrent (and a few
> elsewhere in JDK) could be simplified and updated to use this
> support.
>