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

Vitaly Davidovich vitalyd at gmail.com
Mon Apr 29 19:34:37 EDT 2013


It's not the JIT, of course, that matters but whether the optimizer coming
with it actually does this code motion.  Most likely reason for this type
of thing working is the Dalvik optimizer is still rudimentary and doesn't
hoist cases like this.

Sent from my phone
On Apr 29, 2013 6:15 PM, "Joe Bowbeer" <joe.bowbeer at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/10d39dfe/attachment.html>


More information about the Concurrency-interest mailing list