[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Roman Elizarov elizarov at devexperts.com
Thu Nov 17 06:26:40 EST 2011


Unfortunately, I had to use Unsafe myself from time to time just for performance reasons (because I have to write a lot of high-performance code).

/Roman

From: Dr Heinz M. Kabutz [mailto:heinz at javaspecialists.eu]
Sent: Thursday, November 17, 2011 3:01 PM
To: Roman Elizarov
Cc: Martin Buchholz; concurrency-interest
Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

My thoughts exactly, Roman.  Us mere mortals figure out the "how to" by reading JDK source code and when we see Unsafe being used, we go: "Ah, now that's a good class to use..." ;-)

>From my newsletter:  http://www.javaspecialists.eu/archive/Issue194.html

"In a recent email, one of my youngest readers, 17 year old Mr S.Perlov from the Ukraine, suggested that I tell you about the class sun.misc.Unsafe. Up to now I have avoided writing about it, as it is a class that should be avoided. Here are two reasons: #1 it is "unsafe" and lets us do all the nasty things that we had in C, such as pointer arithmetic or modifying memory directly. #2 it is a sun.misc.* class. You do not know when that might be renamed to oracle.misc.Unsafe or whether you will even run your program on a Sun JVM. By binding yourself to a specific implementation of the JVM, you are limiting the application of your code.

Two reasons to not use Unsafe. I have personally never used Unsafe in production code. Some experts do use it to write directly to memory. Dangerous stuff! "


Regards



Heinz

--

Dr Heinz M. Kabutz (PhD CompSci)

Author of "The Java(tm) Specialists' Newsletter"

Sun Java Champion

IEEE Certified Software Development Professional

http://www.javaspecialists.eu

Tel: +30 69 72 850 460

Skype: kabutz


On 11/17/11 12:53 PM, Roman Elizarov 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 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> [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/f6653b7e/attachment.html>


More information about the Concurrency-interest mailing list