[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

√iktor Ҡlang viktor.klang at gmail.com
Thu Nov 17 06:10:57 EST 2011


On Thu, Nov 17, 2011 at 11:53 AM, Roman Elizarov <elizarov at devexperts.com>wrote:

>  The downside is that it fuels the use of sun.misc.Unsafe by 3rd party
> programmer. Every day there are more and more blogs explaining advantages
> of Unsafe to the average programmer. I’ve just recently reposted one of
> those for the Russian programmers community.****
>
> ** **
>
> Are there any concrete plans (say for Java 8) to bring the performance of
> **Updater classes on par with Unsafe (maybe by improving HotSpot, so that
> it can eliminate all the extra checks and compile **Updater method into the
> same code as produced by direct use of Unsafe)? Shall we co
>
ntinue to rely on Unsafe for Java 8 and beyond
>
or get ready for its eventual elimination from our codebase? ****
>
> **
>

Yes, this is really important. I was under the assumption (yes, always a
bad thing) that the Updater was highly optimized, why would I else use them?

Right now it feels like if you're doing high-perf concurrency in this sense
you have to choose between:

A) Cache-trashing (and extra memory usage) because you went with
AtomicLong/Ref whatnot
B) CPU overhead caused by Atomic*Updaters and if you do any inheritance
you'll get even more checks each call (and extra mem usage due to padding).
C) Sacrifice cross-platform because you had to drop down to Unsafe to get
the correct machinecode emitted.

Would be nice to have "unsafe" versions of all methods of the
Atomic*Updaters that does not do checks each invocation.

Cheers,
√



> **
>
> Sincerely,****
>
> Roman Elizarov****
>
> ** **
>
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *Martin Buchholz
> *Sent:* Thursday, November 17, 2011 3:45 AM
> *To:* Dr Heinz M. Kabutz
> *Cc:* concurrency-interest
> *Subject:* Re: [concurrency-interest] AtomicReferenceFieldUpdater vs
> Unsafe****
>
> ** **
>
> ** **
>
> On Wed, Nov 16, 2011 at 13:37, Dr Heinz M. Kabutz <
> heinz at javaspecialists.eu> wrote:****
>
> In Java 6, classes like ConcurrentLinkedQueue and SynchronousQueue used
> the AtomicReferenceFieldUpdater to update the next, head, etc. fields.
>
> In Java 7, this was changed to instead use Unsafe.compareAndSwapObject()
> directly.
>
> The AtomicReferenceFieldUpdater does a bunch of error checking every time
> it is called, like this:
>
>           if (obj == null || obj.getClass() != tclass || cclass != null ||
>               (update != null && vclass != null &&
>                vclass != update.getClass()))
>               updateCheck(obj, update);
>           return unsafe.compareAndSwapObject(obj, offset, expect, update);
>
> My thinking is that the programmers changing ConcurrentLinkedQueue et al
> probably wanted to improve the performance by not having to do all that
> checking every time it is called.  The Unsafe.compareAndSwapObject() method
> is probably compiled to a single CPU instruction.
>
> Is that correct?****
>
> Yes.****
>
>  ****
>
> Is there any other reason for this change?****
>
>  The previous way was more principled, in the manner of "eat your own
> dogfood".  Maybe we've become just a tiny bit less principled.****
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
Experts

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111117/55c99b18/attachment-0001.html>


More information about the Concurrency-interest mailing list