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. >