Draft JEP on enhanced volatiles
tom.hawtin at oracle.com
Mon Feb 10 03:24:43 UTC 2014
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:
> 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?
More information about the core-libs-dev