[concurrency-interest] VarHandle.setVolatile vs classical volatile write

Paul Sandoz paul.sandoz at oracle.com
Fri Aug 18 15:21:32 EDT 2017

> On 18 Aug 2017, at 11:49, Dávid Karnok <akarnokd at gmail.com> wrote:
> Hi,
> in an older blog post (https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_storeload_barrier_and_stack_usages <https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_storeload_barrier_and_stack_usages>) about write barriers, it is mentioned the JIT uses a stack local address and XADD to flush the write buffer when a volatile field is written on x86 and also mentions the option to use XCHG instead, targeting the actual memory location.
> My question is, does a compiled VarHandle.setVolatile do the same XADD trick or is it using XCHG?

It uses the same trick, since the VarHandles implementation in OpenJDK tunnels through to Unsafe with surrounding safety checks that the compiler folds away when it knows it’s safe to do so.

> Has there been a newer performance evaluation with XCHG since the blog post?

Not that i am aware of.

> In other terms, is there a performance penalty/benefit in changing VarHandle.setVolatile() into VarHandle.getAndSet() when considering a modern x86 ?

I suspect in general there may be a penalty since getAndSet provides stronger ordering (a volatile read and write), so i would hold off with any global search and replace of setVolatile with getAndSet :-)

I would be interested in looking at performance results and generated assembly from some nano benchmarks.


> My particular use case is for running code designed for concurrency in non-concurrent fashion and perhaps saving the cost of a MOVE + XADD pair when an XCHG has the very same effect.
> Thank you for your time.
> --
> Best regards,
> David Karnok
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170818/72a6ff17/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170818/72a6ff17/attachment.sig>

More information about the Concurrency-interest mailing list