Roopa.T PESIT, Bangalore

Source and Credits Dalvik VM, Dan Bornstein Google IO 2008 The Dalvik virtual machine Architecture by David Ehringer

Big Picture

Introduction Android applications are written in Java (some applications are written partly in Java and partly native connected through JNI) The application written in Java source code gets compiled to Java class. This in turn is converted to DVM byte code by a tool called dx. The DVM byte code file has a.dex extension. The DVM loads the application classes from the dex file, executes the application similar to the way JVM does for a Java class file (albeit several key differences)

Why DVM? Goals Run on a slow CPU Limited RAM OS without swap space Battery Powered

Memory Efficiency RAM ODROID-7: 512 MB HTC Desire: 576 MB iPhone: 512 MB Available RAM gets reduced after the low level system start up and high level services Multiple independent mutually suspicious processes Separate address spaces and separate memory Large system library

Architecture Unlike JVM which is a Stack based machine, DVM is a Register based machine. Multiple classes are included in a single.dex file Duplicate strings and other constants used in multiple class files are included only once to save space. Its shown that the uncompressed.dex is much smaller than a compressed.jar file. Dalvik has been designed so that a device can run multiple instances of the VM efficiently. [ [ To address memory constraints and allow for fast startup times, Dalvik shares core, read-only libraries between VM processes. The sharing is done securely by giving the VM processes permission to read the code but not edit it

Class file format vs Dex file format

Constant pool: It stores all the literal constants used in the class like string constants, method names, class names, interface names, field names.dex uses type specific constant pools and duplication of constants is eliminated

Class file format vs Dex file format

Stack vs Register based Virtual Machine Consider an example: public int method( int i1,int i2 ) { int i3 = i1*i2; return i3*2; }

Stack based Virtual Machine Stack based machines use the stack to hold the operands, perform the operation where the result is also stored on the stack iload_1 iload_2 imul istore_3 iload_3 iconst_2 imul ireturn

Register based Virtual machine mul-int v0,v2,v3 ; v0=v2*v3 mul-int/lit-8 v0,v0,2 ; v0=v0*2 return v0

Advantage of Register based VM over Stack based VM Stack based VMs have a simple architecture and provide ease of writing of compiler back end. The JVM is stack based. One stack level can hold any type (char to float) Long and double need 2 consecutive stack levels Implementing stack based operations on a real machine requires memory access and hence stack operations are slower than register operations Register-based architecture requires and average of 47% less executed VM instructions than the stack based [architecture]. On the other hand the register code is 25% larger than the corresponding stack code but this increased cost of fetching more VM instructions due to larger code size involves only 1.07% extra real machine loads per VM instruction which is negligible. The overall performance of the register-based VM is that it takes on average 32.3% less time to execute standard benchmarks Security Engineering Research Group, Institute of Management Sciences. “Analysis of Dalvik Virtual Machine and Class Path Library 2009”

Advantage of Register based VM over Stack based VM Most CPU architectures are register based. RISC architectures support a large number of registers. The above implies that it is easier to map a virtual register based bytecode instruction to a physical machine. For example, consider mul-int v0, v2, v3 that performs: v2 * v3 and places the output on v0. this can be easily mapped to a physical register set with suitable machine instruction