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

Joe Bowbeer joe.bowbeer at gmail.com
Mon Apr 29 18:12:33 EDT 2013


A JIT was added to Android a couple three years ago:

http://android-developers.blogspot.com/2010/05/dalvik-jit.html


On Mon, Apr 29, 2013 at 2: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/e13707eb/attachment.html>


More information about the Concurrency-interest mailing list