[concurrency-interest] Java atomics questions

Boehm, Hans hans.boehm at hp.com
Wed Nov 20 18:31:43 EST 2013


I would assume that putOrderedObject corresponds to lazySet and C11/C++11 memory_order_release (only the last of which has a precise definition).  Which means it kind of, sort of has a StoreStore fence BEFORE it, but that's in general stronger than its definition.

putObjectVolatile presumably corresponds to C/C++ memory_order_seq_cst, and has a trailing fence on x86.  (On Power and ARM, things are much more complicated, and that's not IBM's implementation recommendation.  See http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html.)

Other than that, I agree with what follows.

Hans

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Nathan Reynolds
Sent: Wednesday, November 20, 2013 12:39 PM
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Java atomics questions

I am not the expert here but I would like to take a stab at it... and be corrected.

I think putObjectVolatile() has a full memory fence after it.  Whereas, putOrderedObject() has a store-store memory fence after it.  On x86, the store-store memory fence doesn't emit an instruction since the x86 memory model already forces stores to proceed in order.  However, the memory fence prevents JIT from rearranging the store instructions.

On x86, atomic_fetch_add() ideally would compile into a single instruction: lock xadd.  This is much stronger guarantee than doing a += on a Java volatile.  += would compile to the following...

tmp = atomic_load(&i);
atomic_store(&i, tmp + 666);

> Currently we just add the volatile keyword to the Objective-C field declaration, which doesn't support Java's definition.

This is going to come back to bite you.  I highly recommend supporting Java's definition.  This simply means all accesses to the Java volatile variables must be done with atomic_load and atomic_store.


-Nathan
On 11/20/2013 1:12 PM, Tom Ball wrote:
I'm a member of the J2ObjC<https://code.google.com/p/j2objc/> project, an open-source Jave to Objective-C transpiler. The java.util.concurrent packages have recently been added to its JRE emulation library, but we have some unanswered questions.

The sun.misc.Unsafe class is used by java.util.concurrent.atomic; we have a partial implementation based on Android's version. I'm fuzzy on its distinction between "ordered" and "volatile" field access, though. I assumed that ordered means "requires a memory barrier", while volatile doesn't. Is that correct? Here is our putObjectVolatile()<https://code.google.com/p/j2objc/source/browse/jre_emul/Classes/sun/misc/Unsafe.java#201> and putOrderedObject()<https://code.google.com/p/j2objc/source/browse/jre_emul/Classes/sun/misc/Unsafe.java#287> with that assumption. Look reasonable? (The native comments hold Objective-C, but in this case it's vanilla C.)

Also, is anyone familiar with the C11 optional atomic operations<http://en.cppreference.com/w/c/atomic> support? Clang has the necessary atomic intrinsic functions to support it and generates reasonably looking code, so we're hoping to fix translation of Java volatile fields with it. Currently we just add the volatile keyword to the Objective-C field declaration, which doesn't support Java's definition. Our thoughts for a better translation look something like:

  volatile int i;
...
  i = 42;
  i += 666;

becomes:
  atomic_int i;
...
  atomic_store(&i, 42);
  atomic_fetch_add(&i, 666);

Is that a reasonable approximation of Java volatile field semantics in C11, or is there a better approach?

Tom

P.S. Forgive me my concurrency fumbling -- I realize compiler writers should leave such design to the experts. :-)




_______________________________________________

Concurrency-interest mailing list

Concurrency-interest at cs.oswego.edu<mailto: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/20131120/23a9341d/attachment-0001.html>


More information about the Concurrency-interest mailing list