JEP 193: Enhanced Volatiles

[Florian Weimer]

On 03/05/2014 01:05 AM, Doug Lea wrote:
> On 03/04/2014 05:12 PM, Florian Weimer wrote:
>> On 03/04/2014 01:05 PM, Doug Lea wrote:
>>> On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
>>>> I understand pass-by-reference is an expensive feature, but IMNSHO
>>>> poluting
>>>> Java with this proposal will prove to be more expensive in the long
>>>> run. It's
>>>> like erased generics all over again.
>>>>
>>>
>>> The expensive version of pass-by-reference is already supported
>>> using java.lang.reflect.Field.
>>
>> And per the statistics posted in
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025531.html>,
>>
>> the slightly faster pointer-to-field-member support is one of the
>> prevalent use
>> cases for sun.misc.Unsafe.  That's why I share Jeroen's puzzlement.

> Sorry, I'm not sure what usages you have in mind, or
> what constructions and implementable JVM mechanics
> could be used to deal with them?

If we had lightweight pointer-to-fields, things like compare-and-swap 
could be implemented as regular intrinsics.  It would require less magic 
syntax, and make it clear that the operations only work with non-static 
fields and not on local variables etc.  It would be possible to write 
functions that apply a complex sequence of updates to a field, which is 
impossible under the current proposal.  (One aspect I like about Java is 
that is fairly uniform, e.g., that you can take a subexpression and turn 
it into a function, or that you can store intermediate results, 
something that is often impossible in Ada or C++).

Pointer-to-fields could be as lightweight as a single integer (they are 
in C++ and with sun.misc.Unsafe), assuming that the VM enforces type 
safety.  Whether it is a good idea to add another generic type at the VM 
level before the arrival of reified generics, is a different matter.

-- 
Florian Weimer / Red Hat Product Security Team