[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Roman Elizarov elizarov at devexperts.com
Thu Nov 17 05:53:52 EST 2011


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 continue to rely on Unsafe for Java 8 and beyond or get ready for its eventual elimination from our codebase?

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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111117/cf2f3047/attachment.html>


More information about the Concurrency-interest mailing list