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
