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
