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

Tim Halloran hallorant at gmail.com
Mon Apr 29 17:27:41 EDT 2013


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130429/590f0425/attachment.html>


More information about the Concurrency-interest mailing list