Draft JEP on enhanced volatiles
dl at cs.oswego.edu
Sat Feb 8 15:50:37 UTC 2014
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.)
> 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.
> - 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
> 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
> not in the syntax by itself but in the way the syntax is coupled with a class
> Accessing to the field in order to modifying it will require to pass through an
> 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
> (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.
More information about the core-libs-dev