[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Roman Elizarov elizarov at devexperts.com
Thu Nov 17 08:03:35 EST 2011


Unsafe is big and that’s a separate issue from concurrency patterns (CAS is that we started with). The problem is that ByteBuffer is not as fast as byte[] – even though it uses Unsafe inside, HotSpot is not able to eliminate range checks and translate ByteBuffer usage to an efficient code (while at the same time being very efficient with optimizing byte[] usage). I’ve even reported that fact (that ByteBuffer is slower than byte[]) to Sun bug database several years ago when it first appeared in 1.5 and I did tests on it and it was accepted, but never gained any priority.

/Roman

From: ismaelj at gmail.com [mailto:ismaelj at gmail.com] On Behalf Of Ismael Juma
Sent: Thursday, November 17, 2011 4:02 PM
To: Roman Elizarov
Cc: Martin Buchholz; Dr Heinz M. Kabutz; concurrency-interest
Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

On Thu, Nov 17, 2011 at 10:53 AM, Roman Elizarov <elizarov at devexperts.com<mailto: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.

Yes. A common use of Unsafe these days is to improve the performance of compression algorithms written in pure Java:

https://github.com/dain/snappy/blob/master/src/main/java/org/iq80/snappy/UnsafeMemory.java
https://github.com/ning/compress/blob/master/src/main/java/com/ning/compress/lzf/impl/UnsafeChunkDecoder.java

Off-heap caches too:

https://issues.apache.org/jira/browse/CASSANDRA-3271

It's a shame that this is needed.

Best,
Ismael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111117/043197cd/attachment.html>


More information about the Concurrency-interest mailing list