Draft JEP on enhanced volatiles

[Tom Hawtin]

I'm very concerned that this adds bulk to an already oversized language 
to support something which should be incredibly obscure.

On 07/02/2014 18:36, Doug Lea wrote:
> 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.

I assume by "value type" you mean a type with only constant fields of 
"value types" and no identity (==, System.identityHashCode, monitor or 
equivalents). Clearly volatiles don't fit well there.

There's something that Joe-E calls a "selfless type" which is very 
similar. A selfless type has no identity but may reference reference 
types. It gains the benefits of being an inlineable object, like value 
types, but supports mutable interfaces. That's a perfect fit.

Notionally you would have a selfless type, VolatileInt say, that could 
be implemented as having a reference to an AtomicInteger. As a quality 
of implementation matter, you'd want a JVM that either manages to inline 
the AtomicXxx (assuming selfless types cannot be violated by reflection) 
or intrisifies the whole implementation of VolatileXxx.

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

If the proposed language changes were to be implemented as method 
handles, is there any reason why the updaters couldn't be implemented in 
an equivalent fashion?

Tom