Draft JEP on enhanced volatiles

[Doug Lea]

Thanks for comments! A few collected replies:

On 02/07/2014 01:49 PM, David M. Lloyd wrote:
> I think making the description contingent on a specific syntax might be a
> mistake.

I'm guessing that people who care are so tired of talking
about problems without resolving them that they'll be happy to
see implemented the only proposal so far that covers all the
requirements and for which the strongest negative reaction has
been: "it's a little bit funny looking" :-).

(Well, I'm not counting reactions that seem too unrealistic.
Like "let's add first-class L-values to Java" or
"make people use method-handle-macros".)

> I think that making required performance characteristics (e.g. "must be
> equivalent in performance to Unsafe counterparts") a part of acceptance
> criteria is also something that should be done.

Yes. I don't think this needs writing down though. If people
continue to use Unsafe in these cases for the sake of performance,
we all lose.

On 02/07/2014 03:18 PM, Robert Stupp wrote:
> Would the syntax for array element updates look like this?
>
> long[][] foo; foo[7][42].volatile.compareAndSet(0, 42);
>

Tentatively yes. Details for arrays (as well as non-volatile fields)
ultimately rely on whether, in JMM efforts, we can unify semantics
of operations on non-volatiles with relaxed operations on volatiles.
In C/C++11, these are subtly different, but my guess is that we
can/will unify. If not, usages will be uglier. Also, as only
vaguely mentioned in the JEP (because vague is the best I can do at
the moment), for completeness, the .volatile forms will need to be
augmented with some (static) methods that somehow export the
standalone Unsafe fence method functionality added in JDK8.
(One possibility is to add  such methods to the java.util.Objects
class. Or maybe hide them elsewhere.)

On 02/07/2014 03:44 PM, Brian Goetz wrote:
>
>> We then enable access to corresponding methods for (typically volatile)
>> fields using the ".volatile" prefix. For example:
>
> Is this a prefix or a suffix?

I called it "prefix", since it sets the name resolution
scope for what comes next. But we could just call it a "fix" :-)

> As a limitation, I'd call out that its not obvious how this would scale to
> DCAS.

Right; thanks. Although the issues vary depending on whether
you are dealing with the double-width sense of DCAS (side-by-side
fields of the same object; possibly some sort of "wide" value type)
versus "2CAS" (2 separate vars, a form of transaction). My current
thinking about 2CAS is that for the sake of portable implementation,
we would need to restrict the classes of objects that are 2CASable,
so wouldn't be addressed by this JEP. But some new wide value
type X, if ever supported, could be accommodated by creating a
VolatileX class and using the same rules as for other cases. We'd
want to spec this in a way that make such things is possible.

-Doug