[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

√iktor Ҡlang viktor.klang at gmail.com
Mon Nov 28 09:35:29 EST 2011


On Mon, Nov 28, 2011 at 3:24 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> Relocating these methods to a "proper" JDK class will imply that it's ok
> to use them in normal operation, which I don't think is the case and hence,
> to me, unsafe sounds like the right place.
>
It should probably be java.lang.Unsafe instead of sun.misc.Unsafe though



> Why not have the 3rd party fix their code? I realize that won't help in
> the immediate situation, but that's actually the right solution here.
>
> $.02
>
> Vitaly
> On Nov 28, 2011 1:29 AM, "Hanson Char" <hanson.char at gmail.com> wrote:
>
>> Hi David,
>>
>> Sorry I meant Unsafe#tryMonitorEnter and #monitorExit.  (I realized
>> the mistake after sending out the email, but thought the context would
>> self recover/make it clear :))
>>
>> > Can you expand on this.
>>
>> One practical (and critical) case I've come across is that under some
>> extreme circumstances , a 3rd party database connection pool would get
>> into a "stuck" state.  Doesn't happen often but it does happen.  When
>> it did, any attempt to inspect the respective pool via JMX calling the
>> getter methods for info such as the number of active/idle connections
>> would cause the inspecting thread to get stuck.
>>
>> Looking into the code (of the third party library) it was clearly
>> related to the use of synchronized methods, including the getter
>> methods for the stats.
>>
>> Via Unsafe#tryMonitorEnter, the application was able to get some
>> information out of the pool, and initiate some emergent recovery
>> actions such as interrupting the blocked threads, resetting the db
>> connection pool and jdbc driver, or even just generating alerts/alarms
>> to the support staff.
>>
>> This also allows the application to avoid piling up threads getting
>> sucked into a black hole which would lead to the eventual death of the
>> JVM (ie requiring a restart).
>>
>>  >There's no such proposal on the table at the moment. A tryLock without a
>> > timed-variant is of limited use and monitors don't currently support
>> > timed-acquisition, so there would be a bit of VM work to do -
>> particularly
>> > if you wanted it intrinisfied by the compilers.
>>
>> Indeed that's what I guessed was the reason (of why these two methods
>> are hidden behind Unsafe).  But isn't limited use better than nothing
>> in this case ?  It seems clearly I am not alone:
>>
>>  http://www.javaspecialists.eu/archive/Issue194.html
>>
>> It appears the use of this tryMonitorEnter is the only way we (or just
>> I) can guarantee the application to retain liveness in accessing third
>> party library in face of invoking (3rd party owned) synchronized
>> methods.  As long as there is liveness, the application can do
>> something about it and therefore allow such synchronized problems to
>> be limited to a partial failure that can be recovered.  The use could
>> be limited, but important.
>>
>> I don't know if, however, the tryMonitorEnter/monitorExit method is
>> truly "unsafe" in the sense that if calling them may cause the JVM to
>> crash ?  If not, these methods should probably be re-located to a more
>> sensible class anyway, like perhaps Object ?
>>
>> Regards,
>> Hanson
>>
>> On Sun, Nov 27, 2011 at 8:23 PM, David Holmes <davidcholmes at aapt.net.au>
>> wrote:
>> > Hanson Char writes:
>> >> Performance aside, I find the use of Unsafe#tryMonitor{Enter,Exit}
>> >
>> > tryExit ???
>> >
>> >> 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).
>> >
>> > Can you expand on this. The only use case I can see is if you know the
>> > legacy code will synchronize on a given instance and so you acquire it
>> first
>> > using tryLock. But that only protects you from the initial monitor
>> > acquisition blocking indefinitely. This seems of very limited
>> applicability.
>> >
>> >> 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+ ?
>> >
>> > There's no such proposal on the table at the moment. A tryLock without a
>> > timed-variant is of limited use and monitors don't currently support
>> > timed-acquisition, so there would be a bit of VM work to do -
>> particularly
>> > if you wanted it intrinisfied by the compilers.
>> >
>> > Cheers,
>> > David Holmes
>> >
>> >> 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
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Concurrency-interest mailing list
>> >> Concurrency-interest at cs.oswego.edu
>> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> >>
>> >
>> >
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> 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/20111128/418158ec/attachment.html>


More information about the Concurrency-interest mailing list