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.ll...@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.ll...@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 >
