API review of VarHandles

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 22 13:58:48 UTC 2016


So in this regard, VH ought to be better since it will have performance
like Unsafe (rather than field updaters - is that accurate by the way? Is
VH on par with Unsafe for issuing atomic ops?) and not have the memory
bloat of the instance atomic classes.  Generics is a non-issue for VH.

I do agree with the "this is all just hoop jumping to issue basic memory
ops", but that's more a reflection on Java (memory footprint of atomic
instance classes, generics issues) rather than VH.

On Fri, Jan 22, 2016 at 8:54 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> The costs are both performance and memory overhead.  The
> Atomic*FieldUpdaters are good for memory usage and reasonably usable, but
> suffer from performance problems and generics issues.  The "regular"
> Atomic* classes have good usability (including with generic types) and
> generally very good performance on the actual operations, but generally
> unacceptable memory overhead.  The only way to do atomic array element
> access is via the Atomic*Array though, which has pretty good performance
> but again has memory overhead that can be unacceptable.
>
> Overall this whole thing is a lot of gymnastics for something that's
> basically a fancy way of accessing a plain field or array element - one of
> the most basic concepts in Java.
>
>
> On 01/22/2016 07:40 AM, Vitaly Davidovich wrote:
>
>> Which existing Atomic* classes? I take it you mean the field updaters and
>> not AtomicInteger and friends.  The biggest issue with field updaters is
>> their performance, for me.  I take it you mean something else by "costs"
>> though? Having to specify the target (field) as a string is annoying, and
>> I
>> do wish there was a way javac could assist there.  VH is no worse in this
>> respect, but also no better.
>>
>> On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>> On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:
>>>
>>> Experts need control more than anything else.  This is not to say they'll
>>>> be happy with a subpar API but control typically means lots of details
>>>> so
>>>> there's a limit on how abstracted the API can be.  As mentioned, given
>>>> the
>>>> API provides low level control one can build a higher level one for
>>>> their
>>>> own needs.  The topic of ordering is complex by its nature, there's a
>>>> danger in hiding details in more abstract API.
>>>>
>>>>
>>> I understand that, and that is reasonable.  However, will it be possible
>>> to build higher level APIs on this that do not suffer the same costs that
>>> make the existing Atomic* classes unattractive?
>>>
>>> --
>>> - DML
>>>
>>>
>>
> --
> - DML
>


More information about the valhalla-dev mailing list