Draft JEP on enhanced volatiles

[Remi Forax]

On 02/08/2014 01:49 AM, Doug Lea wrote:
>
> 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".)

It seems I have to answer.
You don't need to have what you call 'method-handle-macros' to implement 
the .volatile syntax,
it's just that having a general mechanism is IMO better for the future 
of Java that having a
mechanism only tailored for the .volatile syntax given that by example 
the JNI-JEP of
Charles Nutter also need the very same mechanism.
Anyway, it's a separate discussion.

Let me try to summarize the problems you mention earlier,
there are two main issues with the current java.util.concurrent.atomic API,
   - erasure of generics,
     because of that, the API implementation does numerous of runtime checks
     which have a cost at runtime hence some users perfers to use the
     unsupported class sun.misc.Unsafe
   - no lvalue or & at language level,
     because of that the volatile field name is passed as a pair (Class, 
String)
     and at runtime

For the former, erasure of generics, we had the same issue with the 
creation of a lambda
because the runtime need the reified types in order to create the proxy 
class
with the right bridges. This was solved by using invokedynamic because 
invokedynamic
allows to pass out of band values representing the non-erased types.

For the later, the .volatile syntax introduces a language level way to 
reference a field,
this is exactly what we want, hooray as Brian wrote. That's true but 
there is a downside,
not in the syntax by itself but in the way the syntax is coupled with a 
class VolatileXXX.
Accessing to the field in order to modifying it will require to pass 
through an instance
of VolatileXXX which introduce an extra level of indirection.
Because of that level of indirection, users may still prefer to use Unsafe.
This problem can be solved if VolatileXXX take a java.lang.reflect.Field 
at construction
(or any values that morally represent a field) and not own the field itself.

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

cheers,
Rémi