JEP 193: Enhanced Volatiles

[David M. Lloyd]

On 03/06/2014 09:25 AM, Florian Weimer wrote:
> 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.

The proposed interface types *could* be used as such a "pointer", with 
the caveats I've given in another branch, that we'd really want the 
object "allocation" to be free or cheap in most cases.

It's one construct that is effectively missing from JUC today.  There is 
a "updater for field X on any object" and "updater for *otherwise 
inaccessible* field X on object Y" but there's no "updater for field X 
on object Y".  The "foo.volatile" syntax *could* provide that, though 
this does run counter to the JEP which indicates that a raw 
"foo.volatile" is not by itself a valid expression.

But the optimizability of the construct is really the key decision axis 
as far as I can see; specifically it would have to be able to optimize 
"foo.volatile.xxx()" constructs directly to the minimal set of 
instructions while still allowing "foo.volatile" to return a real object 
that can be fiddled with by others.  In particular it would be really 
annoying if you had to manually maintain another field to hold this 
hypothetical value of "foo.volatile" to avoid creating a new one every 
time (though I think it's perfectly reasonable for the JVM to create a 
"hidden" field which does this in the case where this value escapes the 
stack).

-- 
- DML