Draft JEP on enhanced volatiles
forax at univ-mlv.fr
Sun Feb 9 12:11:17 UTC 2014
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
> 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
That's why these methods were put in Unsafe after all.
>> - erasure of generics,
>> because of that, the API implementation does numerous of runtime
>> 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
>> 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
>>>> I think that making required performance characteristics (e.g.
>>>> "must be
>>>> equivalent in performance to Unsafe counterparts") a part of
>>>> 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