Dalvik VM and Java memory model (simultaneous programming on Android)

Question

I am working on Android projects that are associated with many concurrent programs, and I am going to implement some custom materials for interaction between threads (one of java.util.concurent is not suitable for my purposes).

Concurrent programming is not easy in general, but with Dalvik it seems even more complicated. To get the correct code, you need to know some specific things and that where the problem arises with Dalvik. I just can't find the detailed documentation for Dalvik VM. Most Android resources (even developer.android.com are focused on the platform API and do not provide any in-depth information about some non-trivial (or low-level) things).

For example, to which editor of the Java language specification does Dalvik VM correspond? Depending on the response, the handling of volatile variables is different and affects any parallel code that uses volatile variables.

There are already some related questions:

• Is the Dalvik memory model the same as Java?
• Double lock check in Android

and some fadden answers are very useful, but I still want to get a more detailed and complete understanding of the issue at hand.

So, under the raw questions that interest me (I will update the list if necessary when the answers to previous questions come):

• Where can I find detailed information about the Dalvik VM that can provide answers to the questions below?
• Which edition of the Java language specification does Dalvik VM comply with?
• If the answer to (2) is the “third edition”, then how complete is the support for the Dalviks Java Memory Model in this specification? And especially, how full is the support for the semantics of volatile variables?

• In the Double Lock Check in Android fadden, specify the following comment:

  Yeah. With the addition of the “volatile” keyword, this will work on uniprocessor (all versions of Android) and SMP (3.0 “cell” and later)

  Does this mean that the Samsung Galaxy SII , which has a dual-core processor, but only Android 2.3, can execute parallel code incorrectly? (Of course, Galaxy is just an example, a question about any multi-core device with a platform up to Android 3.0)

• Is the Dalvik memory model the same as Java? fadden provides an answer with the following sentence:

  Dalvik version is currently not true for JSR-133

  Does this mean that any existing correct parallel Java code may not work correctly on any version of Android released prior to the date of publication of this comment?

Update # 1: reply to @gnat comment (too long for comment)

@gnat leave a comment:

@Alexey Dalvik does not match any JLS release because matching requires a JCK transfer, which is not an option for Dalvik. Does this mean that you can’t even use the standard Java compiler, since it complies with the standard specification? does it matter? if so, how?

Well, my question was somehow controversial. I actually meant that JLS are not only rules for implementing Java compilers, but also implicit recommendations for any JVM implementations. Indeed, JLS, for example, claims that reading and writing certain types are atomic operations. This is not very interesting for the compiler, because the read / write is translated into just one operation code. But for any JVM implementation, it is very important to correctly implement these opcodes. Now you have to understand what I'm talking about. Although Dalvik accepts and executes programs compiled with the standard Java compiler, there is no guarantee that they will execute correctly (as expected) just because no one (except maybe Dalvik developers) knows if all the JLS functions used in program, Dalvik.

It's clear that JCK is not an option for Dalvik, and that's fine, but programmers really need to know which JLS functions they can rely on when they execute their Dalvik code. But in the documentation there are no words about it. Although you can expect the simplest operators like =, +, -, *, etc. What do you expect about nontrivial functions, such as the semantics of volatile variables (which differs in the 2nd and 3rd releases of JLS)? And the last - these are not the most non-trivial things that you can find in JLS and especially in the Java Memory Model.

Answer 1

I have not completely read your question, but first of all do not use volatile ones, even opengles encoders do not use it for different ui vs renderer streams.

Use volatile if and only if one thread writes (say, for a static property of some class) and other readings, even then you need to synchronize, read this for some good ways to handle samples

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

• always use sync
• do not jump in large projects for such complex topics as parallel programming.
• Check out the Android samples in games where they discussed the concept of runnables, handlers and b / w threads (UI THREAD AND RENDERER THREAD).

Answer 2

I think you answered your question, although you did not provide any details as to why the java.util.concurrent package does not meet your needs, most mobile applications just use asynchronous I / O and a minimum of threads. These devices are not supercomputers capable of serious distributed processing, so I am a little at a loss to understand why java.util.concurrent does not satisfy your needs.

Secondly, if you have questions about the implementation of Dalvik and whether it complies with JLS (this is not so), it would seem that the reason is that the only reliable support for streaming mechanisms is what the language defines - java.util. parallel, runnable and local thread storage.

A hand that flips anything beyond the built-in language support only poses problems, and as your question suggests, it probably won't be supported in a consistent way in Dalvik.

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

Answer 3

<copied from comment> Dalvik does not match any JLS edition because matching requires a JCK transfer, which is not an option for Dalvik. </ copied from comment>

programmers really need to know what JLS functions they can rely on when they execute their Dalvik code

I think the only way to get to know them is to study the Dalvik test suite (I'm sure it is one, and I expect it to be open source, right?). For any function that you need, 1) try to find a test that will fail if your function is not implemented correctly and check if the test is enough. If there is no such test or it is not good enough, 1a) add a new test or improve an existing test. Then 2) find out if the test passed successfully against your target implementation. If the test has not been started, then 2a) run it yourself and find out if it passes or does not work.

BTW above is about how JCK works. The main difference is that you need to spend your own time and effort on Dalvik for the things you get from Sun / Oracle for granted. Another difference seems to be that for Dalvik this is not documented, and Snorcle has clear documents that iirc

But there are no words in the documentation.

Well, if there are no words on it, I would say that the quality of the Dalvik documentation is sub-optimal. To put it mildly

Answer 4

Here is an honest answer. If java.util.concurrent does not match the task for your implementation, then your problem is not in java.util.concurrent, but in your original design specifications. Review your design, perhaps post here what your design does using a simple mutex, not a task for you, and then the community can show you how to create it better.