[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android

Gregg Wonderly gergg at cox.net
Mon Apr 29 18:10:13 EDT 2013


This code exists everywhere on the Java JVM now, because no one expects the loop hoist…   People are living with it, or eventually declaring the loop variable volatile after finding these discussions.  

Java, by default, should of used nothing but volatile variables, and developers should of needed to add non-volatile declarations via annotations, without the 'volatile' keyword being used, at all.

That would of made it hard to "break" code without actually looking up what you were doing, because the added verbosity would only be tolerated when it actually accomplished a performance improvement.  Today, code is "Faster" without "volatile".   If everything was "volatile" by default, then code would be slower to start with, and proper "concurrency programming" would then make your code faster, as concurrency should.

Gregg

On Apr 29, 2013, at 4:27 PM, Tim Halloran <hallorant at gmail.com> wrote:

> Yuval,
> 
> Dalvik won't hoist the expression. I'm sure of that.  For example, the snippet below:
> 
> boolean flag;
> 
> In one thread:
> void run() {
>   while (!flag) {
>     // todo
>   }
> }
> 
> In another thread (later on):
> flag = true;
> 
> On JIT it never terminates due to hoisting inside the JIT (the compiler is not doing the optimization) (Windows, Mac OS, Linux). Today, on Android this program works. (At least on a whole lot of Android devices I've tried it on anyway.)
> 
> Sadly, if they add JIT to Dalvik a whole lot of Android apps are going to break. :-(  I've found several open source examples that rely upon this broken code behaving as it does on Dalvik today.
> 
> 
> On Mon, Apr 29, 2013 at 5:16 PM, Yuval Shavit <yankee.sierra at gmail.com> wrote:
> If the action in thread 2 doesn't update $a, isn't the JVM still within its rights to hoist it from the loop? And even if thread 2 does write to $a within the loop, isn't the JVM within its rights to update that in some register and never write it to main memory where it could interact with the writes from thread 1? In other words, in the absence of any HB (since $a isn't volatile), can't the JVM just pretend they're entirely separate variables?
> 
> 
> On Mon, Apr 29, 2013 at 4:59 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> Yes, that's exactly what I had in mind:
>  a. Declare "long a"
>  b. Ramp up two threads.
>  c. Make thread 1 write 0L and -1L over and over to field $a
>  d. Make thread 2 observe the field a, and count the observed values
>  e. ...
>  f. PROFIT!
> 
> P.S. It is important to do some action on value read in thread 2, so
> that it does not hoisted from the loop, since $a is not supposed to be
> volatile.
> 
> -Aleksey.
> 
> On 04/30/2013 12:54 AM, Tim Halloran wrote:
> > Thanks Aleksey, can you elaborate on how to reproduce this in the wild?
> >
> > Are you thinking of writing xFFFFFFFF_FFFFFFFF (or some known bit
> > pattern/long value) and x00000000_0000000 (another known bit
> > pattern/long value) from two different threads and seeing if you get
> > x00000000_FFFFFFFF or xFFFFFFFF_00000000 -- or did you have another
> > scheme in mind.  Best.
> >
> >
> > On Mon, Apr 29, 2013 at 4:42 PM, Aleksey Shipilev
> > <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> >
> >     On 04/30/2013 12:27 AM, Tim Halloran wrote:
> >     > Does anyone know if Android's Dalvik goes with the recommendation
> >     in JLS
> >     > 17.7 and avoids splitting 64-bit values. I'm pretty sure most
> >     other VMs do.
> >
> >     You might safely assume ARM does not have full-width 64-bit reads/writes
> >     (it can emulate atomic read/write with LL/SC-ed loop), so I'm pretty
> >     sure non-volatile longs are not atomic on most mobile platforms.
> >
> >     > After some searching I couldn't find any information and it seems
> >     pretty
> >     > hard to write code to "test" for this on the VM.
> >
> >     It is actually one of the simplest tests for concurrency, and simple
> >     enough to reproduce in the wild.
> >
> >     -Aleksey.
> >
> >
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 
> _______________________________________________
> 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/20130429/b09a79fa/attachment-0001.html>


More information about the Concurrency-interest mailing list