Note that there are some explanatory texts on larger screens.

plurals
  1. PODalvik VM & Java Memory Model (Concurrent programming on Android)
    text
    copied!<p>I am working on Android projects which involve the lot of concurrent programming and I am going to implement some custom inter-threads communication stuff (the one from <strong>java.util.concurent</strong> are not well suited for my purposes).</p> <p>The concurrent programming is not easy in general but with Dalvik it seems to be even harder. To get the correct code you should know some specific things and that where problem arise with Dalvik. I just can't find a detailed documentation about the Dalvik VM. Most Android resources (even the <strong>developer.android.com</strong> focused on platform API and doesn't provide any deep information about some non-trivial (or low-level) things).</p> <p>For example, to which edition of <em>Java Language Specification</em> the Dalvik VM is conform ? Depending of answer the treatment of <code>volatile</code> variables are different and affect the any concurrent code which use the <code>volatile</code> variables.</p> <p>There are already some related questions:</p> <ul> <li><a href="https://stackoverflow.com/questions/4588076/is-dalviks-memory-model-the-same-as-javas">Is Dalvik's memory model the same as Java's?</a></li> <li><a href="https://stackoverflow.com/questions/5717090/double-checked-locking-in-android">Double checked locking in Android</a></li> </ul> <p>and some answers by <strong>fadden</strong> are very useful but I still want to get more detailed and complete understanding of matter in question.</p> <p>So below a raw questions I am interesting in (I will update the list if necessary as answers for previous questions will arrive):</p> <ol> <li>Where to find the details about the Dalvik VM which may provide the answers for questions below ?</li> <li>To which edition of <em>Java Language Specification</em> the Dalvik VM is conform to ?</li> <li>If answer to (2) is "third edition" then how complete the Dalviks's support of <em>Java Memory Model</em> defied in this specification ? And especially how complete the support for semantic of <code>volatile</code> variables ?</li> <li><p>In the <a href="https://stackoverflow.com/questions/5717090/double-checked-locking-in-android">Double checked locking in Android</a> the <strong>fadden</strong> provide the following comment:</p> <blockquote> <p>Yup. With the addition of the "volatile" keyword, this will work on uniprocessor (all versions of Android) and SMP (3.0 "honeycomb" and later)</p> </blockquote> <p>Does it mean that <strong>Samsung Galaxy SII</strong> which has the dual-core CPU but only Android 2.3 may execute the concurrent code incorrectly ? (of course Galaxy is only an example, the question is about of any multicore device with pre-Android 3.0 platform)</p></li> <li><p>In the <a href="https://stackoverflow.com/questions/4588076/is-dalviks-memory-model-the-same-as-javas">Is Dalvik's memory model the same as Java's?</a> the <strong>fadden</strong> provide the answer with the following sentence:</p> <blockquote> <p>No currently-shipping version of Dalvik is entirely correct with respect to JSR-133</p> </blockquote> <p>Does it mean that any existing correct concurrent Java code may work incorrectly on any Android version released up to date of posting of this comment ?</p></li> </ol> <h2>Update#1: Answer to @gnat's comment (too long to be comment too)</h2> <p>@gnat post a comment:</p> <blockquote> <p>@Alexey Dalvik does not conform to any JLS edition, because conformance requires passing JCK which is not an option for Dalvik. <em>Does it mean that you even can't apply standard Java compiler because it conform to standard specification ?</em> does that matter? if yes, how?</p> </blockquote> <p>Well, my question was somehow ambiguous. What I actually meant is that <em>JLS</em> is not only the rules for Java compiler implementations but also an <em>implicit</em> guidelines for any <em>JVM</em> implementations. Indeed, <em>JLS</em>, for example, states that reading and writing of some types are <em>atomic</em> operations. It is not very interesting for compiler writer because read/write translated just into a single opcodes. But it is essential for any <em>JVM</em> implementation which <em>should</em> implement these opcodes properly. Now you should see what I am talking about. While Dalvik accept and execute the programs compiled with standard Java compiler there are <strong><em>no any guaranties</em></strong> that they are executed <strong><em>correctly</em></strong> (as you may expect) just because no one (except maybe Dalvik's developers) knows if all JLS's features used in the program are supported by Dalvik.</p> <p>It is clear that <em>JCK</em> is not an option for Dalvik and it is Ok, but programmers really should know on which <em>features</em> of <em>JLS</em> they may rely when execute their code on Dalvik. But there is no any words about this in documentation. While you may expect that simplest operators like =, +, -, *, etc. are works as you expect what about non-trivial <em>features</em> like semantic of <code>volatile</code> variables (which is different in 2nd and 3rd editions of <em>JLS</em>)? And latter is not the most non-trivial things you may find in <em>JLS</em> and particular in <em>Java Memory Model</em>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload