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

Tim Halloran hallorant at gmail.com
Tue Apr 30 00:07:28 EDT 2013

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/55781384/attachment.html>

More information about the Concurrency-interest mailing list