[concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

Roman Elizarov elizarov at devexperts.com
Thu Nov 17 08:11:00 EST 2011


Doug,

Frankly, I don't see what is preventing HotSpot team to look into it and make sure that a code using **Updater classes is translated to the direct native instructions. There are multiple equally feasible approaches starting from recognition 
of select **Updater methods as intrinsics (whenever their usage permits) or learning typical cases where the checks in **Updater classes can be eliminated, so that HotSpot inlining & Unsafe intrinsics can do their job at producing efficient machine code.

The only thing that is need is priority to this project. And that needs some decisions first. If sun.misc.Unsafe is there to stay in all major JVMs, then Ok -- let everybody use it for their high-performance code. They will not work in sand-boxed scenarios, but one can argue that nobody need high-performance concurrency in a sandbox anyway.

Sincerely,
Roman Elizarov

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Doug Lea
Sent: Thursday, November 17, 2011 4:37 PM
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] AtomicReferenceFieldUpdater vs Unsafe

On 11/17/11 06:10, √iktor Ҡlang wrote:
> Right now it feels like if you're doing high-perf concurrency in this sense you
> have to choose between:
>
> A) Cache-trashing (and extra memory usage) because you went with AtomicLong/Ref
> whatnot
> B) CPU overhead caused by Atomic*Updaters and if you do any inheritance you'll
> get even more checks each call (and extra mem usage due to padding).
> C) Sacrifice cross-platform because you had to drop down to Unsafe to get the
> correct machinecode emitted.
>

Yes.

The main underlying problem is a fundamental one: Java bytecodes
support only two field read/write operations (getField/putField),
plus an implicit mode argument for volatiles. However, there is no
casField, or special r/w modes like releaseField. One level up,
there is no syntax for "lvalue" operations on fields. So the
only options are to directly invoke these lvalue operations
via Unsafe, which require that you know the address of the field,
or to use Updaters, that don't require the address, but must
perform type checks and security checks that you have access to the
field.

No one knows of any good alternatives. We tried for Java7
to reduce need for either option by proposing Fences that
would at least emulate the different memory modes, but that's
also problematic enough to not be worth adopting.

It's not hard to imagine some nicer syntax to support
these operations (as in a.someField.compareAndSet(x, y))
and also to perform class-loading-time validations (similarly
to "quickening") and/or using invokeDynamic. But these matters
never attain high enough priority when people consider syntax
enhancements.

Portability of Unsafe constructions is not really a problem.
We frequently communicate with all production JVM implementors
to help ensure that they are correctly supported.

-Doug


_______________________________________________
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