Draft JEP on enhanced volatiles

[Remi Forax]

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