How the Dalvik Virtual Machine Works on Google Android

http://www.ctoedge.com/content/how-dalvik-virtual-machine-works-google-android

How the Dalvik Virtual Machine Works on Google Android
Mobile Computing | How-To | Sayed Hashimi, Satya Komatineni & Dave MacLean, Monday, March 8, 2010
Tags: Android, Google, smartphones

(The following is an excerpt from "Pro Android 2," published by APress)
As part of Android, Google has spent a lot of time thinking about optimizing designs for low-powered handheld devices. Handheld devices lag behind their desktop counterparts in memory and speed by eight to ten years. They also have limited power for computation; a handheld device’s total RAM might be as little as 64MB, and its available space for applications might be as little as 20MB.
The performance requirements on handsets are severe as a result, requiring handset designers to optimize everything. If you look at the list of packages in Android, you’ll see that they are full-featured and extensive. According to Google, these system libraries might use as much as 10 to 20MB, even with their optimized JVM.
These issues led Google to revisit the standard JVM implementation in many respects. (The key figure in Google’s implementation of this JVM is Dan Bornstein, who wrote the Dalvik VM—Dalvik is the name of a town in Iceland.) First, the Dalvik VM takes the generated Java class files and combines them into one or more Dalvik Executable (.dex) files. It reuses duplicate information from multiple class files, effectively reducing the space requirement (uncompressed) by half from a traditional .jar file. For example, the
.dex file of the web browser app in Android is about 200K, whereas the equivalent uncompressed .jar version is about 500K. The .dex file of the alarm clock app is about 50K, and roughly twice that size in its . jar version.
Second, Google has fine-tuned the garbage collection in the Dalvik VM, but it has chosen to omit a just-in-time (JIT) compiler, in early releases. The 2.0 codebase seem to have the necessary sources for a JIT compiler but is not enabled in the final release. It is anticipated that it will be part of future releases. The company can justify this choice because many of Android’s core libraries, including the graphics libraries, are implemented in C and C++. For example, the Java graphics APIs are actually thin wrapper classes around the native code using the Java Native Interface (JNI). Similarly, Android provides an optimized C-based native library to access the SQLite database, but this library is encapsulated in a higher-level Java API. Because most of the core code is in C and C++, Google reasoned that the impact of JIT compilation would not be significant.
Finally, the Dalvik VM uses a different kind of assembly-code generation, in which it uses registers as the primary units of data storage instead of the stack. Google is hoping to accomplish 30 percent fewer instructions as a result. We should point out that the final executable code in Android, as a result of the Dalvik VM, is based not on Java byte code but on .dex files instead. This means you cannot directly execute Java byte code; you have to start with Java class files and then convert them to linkable .dex files.