Dalvik VM & Java Memory Model (Concurrent programming on Android)

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 java.util.concurent are not well suited for my purposes).

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 developer.android.com focused on platform API and doesn't provide any deep information about some non-trivial (or low-level) things).

For example, to which edition of Java Language Specification the Dalvik VM is conform ? Depending of answer the treatment of volatile variables are different and affect the any concurrent code which use the volatile variables.

There are already some related questions:

• Is Dalvik's memory model the same as Java's?
• Double checked locking in Android

and some answers by fadden are very useful but I still want to get more detailed and complete understanding of matter in question.

So below a raw questions I am interesting in (I will update the list if necessary as answers for previous questions will arrive):

1. Where to find the details about the Dalvik VM which may provide the answers for questions below ?
2. To which edition of Java Language Specification the Dalvik VM is conform to ?
3. If answer to (2) is "third edition" then how complete the Dalviks's support of Java Memory Model defied in this specification ? And especially how complete the support for semantic of volatile variables ?

4. In the Double checked locking in Android the fadden provide the following comment:

   Yup. With the addition of the "volatile" keyword, this will work on uniprocessor (all versions of Android) and SMP (3.0 "honeycomb" and later)

   Does it mean that Samsung Galaxy SII 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)

5. In the Is Dalvik's memory model the same as Java's? the fadden provide the answer with the following sentence:

   No currently-shipping version of Dalvik is entirely correct with respect to JSR-133

   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 ?

Update#1: Answer to @gnat's comment (too long to be comment too)

@gnat post a comment:

@Alexey Dalvik does not conform to any JLS edition, because conformance requires passing JCK which is not an option for Dalvik. Does it mean that you even can't apply standard Java compiler because it conform to standard specification ? does that matter? if yes, how?

Well, my question was somehow ambiguous. What I actually meant is that JLS is not only the rules for Java compiler implementations but also an implicit guidelines for any JVM implementations. Indeed, JLS, for example, states that reading and writing of some types are atomic operations. It is not very interesting for compiler writer because read/write translated just into a single opcodes. But it is essential for any JVM implementation which should 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 no any guaranties that they are executed correctly (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.

It is clear that JCK is not an option for Dalvik and it is Ok, but programmers really should know on which features of JLS 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 features like semantic of volatile variables (which is different in 2nd and 3rd editions of JLS)? And latter is not the most non-trivial things you may find in JLS and particular in Java Memory Model.

I haven't read your question completely, but first of all do not use volatile, even opengles coders do not use it for different ui vs renderer threads.

Use volatile if and only if one thread writes (say to some class' static property) and other reads, even then you have to synchronize, read this for some good ways to handle counts

How to synchronize a static variable among threads running different instances of a class in java?

1. always use synchronize
2. do not jump at large projects for such difficult topics like concurrent programming
3. go through android samples on games where they have discussed the concept of runnables, handlers, and exchanging messages b/w threads (UI THREAD AND RENDERER THREAD).

I think you answered your own question, although you have given no details as to why the java.util.concurrent package does not fit your needs, most mobile apps simply use asynchronous IO and a minimum of threading. These devices aren't super computers capable serious distributed processing so I have a little difficulty understanding why java.util.concurrent wont meet your needs.

Secondly, if you have questions about the Dalvik implementation and whether it conforms to the JLS (it doesnt), it would seem to reason that the only reliable support for threading mechanisms would be those which the language defines - java.util.concurrent, runnable and thread local storage.

Hand rolling anything outside of the built in language support is only asking for trouble, and as your question suggests will likely not be supported in a consistent manner on Dalvik.

As always when you think you can do threading better than the guys who wrote Java, think again.