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

Roman Elizarov elizarov at devexperts.com
Tue Apr 30 00:21:59 EDT 2013

See "Adversarial Memory for Detecting Destructive Races"
It will catch the aforementioned bug on the first run.

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Tim Halloran
Sent: Tuesday, April 30, 2013 8:07 AM
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android

Thanks for the Dalvik JIT pointer.

I should have said, as Vitaly corrected:

Sadly, if they add a loop invariant hoisting optimization 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.

This optimization seems to be less dependent on the chip (ARM vs Intel) than how much analysis the JIT optimizer is willing to spend time trying to do. I guess it is dependent upon how good the CPU is at allowing cycles for optimization, but beyond that it is a portable optimization.

(pie in the sky thought) This all makes me ponder that it might be ideal to make the memory model implementation as close to the JMM specification as possible, ideally in a way that makes "broken" programs behave in a obviously broken manner. The more conservative (toward sequential consistency, I guess) a platform implementation is (HotSpot on Intel, Android on ARM) the more likely code depends upon behavior that exists in the platform implementation that isn't specified by the JMM. In Brooks-speak I'm wondering if the platform implementations are accidental or essential complexity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/30a4044f/attachment.html>

More information about the Concurrency-interest mailing list