[concurrency-interest] FieldReference vs. AtomicFieldUpdater - was Re: Optimizing Atomic*FieldReference <was> Re: Here's why Atomic*FieldReference access checking is broken

David M. Lloyd david.lloyd at redhat.com
Thu Oct 9 15:42:46 EDT 2014

On 10/09/2014 12:33 PM, Paul Sandoz wrote:
> On Oct 8, 2014, at 11:19 AM, Peter Levart <peter.levart at gmail.com
> <mailto:peter.levart at gmail.com>> wrote:
>> Hi Paul,
>> Since this thread is way from original topic, I changed it. It is very
>> interesting though.
>> On 10/08/2014 06:00 PM, Paul Sandoz wrote:
>>> On Oct 8, 2014, at 7:16 AM, Peter Levart<peter.levart at gmail.com>  wrote:
>>>> On 10/08/2014 01:19 PM, Doug Lea wrote:
>>>>> On 10/08/2014 05:38 AM, Peter Levart wrote:
>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java
>>>>> Paul Sandoz has been working on VarHandles (like MethodHandles)
>>>>> for similar purposes. Possibly even the same purposes.
>>>>> See his JavaOne talk slides at
>>>>> http://cr.openjdk.java.net/~psandoz/j1-2014-unsafe-CON5150.pdf
>>>>> It seems worth waiting for more progress on this front before
>>>>> contemplating changes along these lines.
>>>>> -Doug
>>>> Thanks Doug for pointing me to Paul's slides. I can see that Paul's VarHandles are based around the idea of methods with polymorphic signature akin to MethodHandles.invoke* with the benefit that they don't declare Throwable as thrown exception and he's adding some type inference changes on top of that.
>>>> Paul is exploring alternative approaches to JEP 193 which don't require language changes although he has already stepped beyond that line as I can see that his patch contains a few lines of javac changes.
>>> Yes, it requires some small changes to how polymorphic signature methods are expressed but requires no new language syntax. The downside is the specs require updating to say "here is another class with polymorphic signature methods" so it is not very general.
>> And I think you also showed on your slides, that polymorphic signature
>> methods don't provide static type checking. Are there any plans to
>> merge polymorphic signature methods with generic types? Currently both
>> polymorphic signature methods that I know of
>> (MethodHandle.invoke[Exact]) allow passing any type and number of
>> arguments and return Object. Would it be possible to have
>> "constrained" polymorphic signature methods that are static
>> type-checked as normal methods, but otherwise "behave" like
>> polymorphic signature methods?
> It's possible:
> http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/bc9fae81d774/src/java.base/share/classes/java/lang/invoke/FieldHandle.java
> http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/bc9fae81d774/src/java.base/share/classes/java/lang/invoke/ArrayHandle.java
> (These support a hack that avoids boxing, i referred to in my last
> email, so explicit int/long versions are not required.)
> There is a tension here between what we do for Java 9 and what we can do
> later on when specialization arrives.
> You can find more stuff here:
> http://cr.openjdk.java.net/~psandoz/varhandles/

This is all quite interesting exploration.  But I admit I'm having a 
hard time understanding why this apparently more complex mechanism is 
better than *Updaters, especially if the latter has as much room for 
optimization as Peter's work suggests.  While a few extra capabilities 
have been added and changed, from the perspective of a user the only 
difference from *Handles to *Updaters seems to be that considerably more 
of the implementation details have bubbled up to the surface with 
*Handles, making them somewhat more difficult to understand, and making 
the apparent expected usage seem much more complex than *Updaters (or 
the [apparently DOA?] proposed .volatile idea, with its virtual objects, 
which I personally liked a lot better, as a user who is a human being 
and not some kind of complex embodiment of a deparser algorithm).


More information about the Concurrency-interest mailing list