[concurrency-interest] jdk9 VarHandle and Fence methods

Doug Lea dl at cs.oswego.edu
Sun Aug 23 07:16:09 EDT 2015

On 08/22/2015 12:47 PM, thurstonn wrote:

> What are the plans with respect to the "higher-order methods" on e.g.
> AtomicReference, i.e.
> T getAndAccumulate(T, BinaryOperator<T>)
> T updateAndGet(UnaryOperator<T>)

No plans; basically for the reasons you noted: There are too many
possibilities to support, all of them can be done on top of what
we do provide, and they don't fit well with the polymorphic
signature mechanics.

> And one final question that I've always been confused about;  are there
> different "memory ordering effects" between a successful CAS and an
> unsuccessful one (presumably in the latter because no write actually
> occurs)?

The memory ordering effects are the same regardless of outcome.
Ensuring this sometimes takes some thought on ARM -- see some
exchanges on this list last fall(?).

> IIRC, when looking at the java 8 JVM code, I believe a fence was inserted in
> the successful case, at least on x86/64.  If so, I can take a shot at
> producing some javadoc language to reflect that, if it would be helpful.

There is no extra fence on x86. (Hotspot sometimes prevents
internal IR reorderings using the (misnamed) MemBarCPUOrder
just for internal reasons. This might be what you were seeing.)


More information about the Concurrency-interest mailing list