Draft JEP on enhanced volatiles

[Doug Lea]

On 02/09/2014 10:24 PM, Tom Hawtin wrote:
> I'm very concerned that this adds bulk to an already oversized language to
> support something which should be incredibly obscure.

A lot of us started out with the same concerns, but after
a decade of exploration, we don't know of a defensible alternative.
Back in JDK5, this functionality was needed by at most a dozen
people writing code near the Java/JVM borderline. Using second-class
cheats to work around lack of language support seemed acceptable.
Barely acceptable, because they rely on Unsafe constructions that
require special care to ensure safety otherwise guaranteed by JVMs,
so increase the size of the trusted code base.
Over the past decade the use of concurrent algorithms requiring
fine-grained atomicity and ordering control intrinsics (which
we periodically add to)  has expanded to include cases not
just isolated to low-level software. Enough so that other
languages standards (including C/C++11) define them as intrinsics.
Without better support, people needing them in Java will use
Unsafe more. Or will use Java less.

Among the constraints on solution is that several of these
methods compile down to no-ops on many common platforms.
Any further overhead encountered in arranging to do
nothing has a good chance of measurably impairing some of
the best concurrency support offered on any platform.

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

Not so perfect. For the memory semantics to be meaningful, the
field MUST be a component, not MAY be. It is possible in
theory to make a zillion JVM changes to correctly emulate this,
but it is not a realistic option. More realistically, this might be
approachable via "Packed" in a variant of the IBM Packed Object
proposal. But this would be a more significant language change
than adding .volatile expressions.

-Doug