Delving into the Dalvik VM

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.

Note For example, the T-Mobile G1 phone, released in late 2008, comes with 192MB of RAM, a 1GB SD card, and a 528 MHz Qualcomm MSM7201A processor. Compare that to the lowest-priced Dell laptop, which comes with a 2.1 GHz dual-core processor and 2GB of RAM.

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 in number. According to Google, these system libraries might use as much as 10MB, even with their optimized JVM.

chapter 1 ■ INTRODUCING THE android computing platform

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 and named it after 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 this release at least. 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 bytecode but on .dex files instead. This means you cannot directly execute Java bytecode; you have to start with Java class files and then convert them to linkable .dex files.

This extreme performance paranoia extends into the rest of the Android SDK. For example, the Android SDK uses XML extensively to define UI layouts. However, all of this XML is compiled to binary files before these binary files become resident on the devices. Android provides special mechanisms to use this XML data.

While we are on the subject of Android's design considerations, we should answer this question: How would one compare and contrast Android to Java Platform, Micro Edition (Java ME)?

0 0

Post a comment