[concurrency-interest] Java atomics questions

Nathan Reynolds nathan.reynolds at oracle.com
Wed Nov 20 15:39:11 EST 2013


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
> 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/9f846cf9/attachment.html>


More information about the Concurrency-interest mailing list