[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Hanson Char hanson.char at gmail.com
Sat Nov 26 19:45:19 EST 2011


Performance aside, I find the use of Unsafe#tryMonitor{Enter,Exit}
extremely valuable in face of legacy code that uses synchronized
block/method but the caller cannot afford to be "trapped" when calling
the legacy code even when it entered into a indefinitely blocking
state (within the synchronized block/method).

It would be really nice if the tryMonitor{Enter,Exit} can be promoted
into a normal and safe jdk class for general use, so we don't need to
use it in stealth mode.  Or maybe it already is in Java 7+ ?

Regards,
Hanson

On Thu, Nov 17, 2011 at 3:26 AM, Roman Elizarov <elizarov at devexperts.com> wrote:
> 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] 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
>
>



More information about the Concurrency-interest mailing list