API review of VarHandles
David M. Lloyd
david.lloyd at redhat.com
Fri Jan 22 13:54:26 UTC 2016
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 core-libs-dev
mailing list