API review of VarHandles
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>
> 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
>> 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>
>> 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
>>>> there's a limit on how abstracted the API can be. As mentioned, given
>>>> API provides low level control one can build a higher level one for
>>>> 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 core-libs-dev