On 02/08/2014 04:50 PM, Doug Lea wrote:
On 02/08/2014 06:19 AM, Remi Forax wrote:
It seems I have to answer.
You don't need to have what you call 'method-handle-macros' to
implement the
.volatile syntax,
(Aside: I love macros enough to want them to be done right someday,
but they seem to be the wrong plan of attack for this problem.)
What I propose is not macros but a way to write intrinsics in Java,
which I think is the right way to tackle this problem, at API level,
you can still see intrinsics has a kind of macro system, but I don't
think it helps.
Let me try to summarize the problems you mention earlier,
there are two main issues with the current
java.util.concurrent.atomic API,
Another: There is a (very!) undesirable but available fallback for
.volatile
that doesn't apply to FieldUpdaters: If method handles don't work
out, generate exactly the same Unsafe code that we manually write
today, with some crazy further fallback if run on a JVM not
supporting the intrinsics.
I think you can not do that, because for that you need to publicly
expose the methods of Unsafe,
so someone may generate a bytecode that call these methods creating a
security hole.
That's why these methods were put in Unsafe after all.
-Doug
Rémi
- 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
