The success of any modern smartphone platform is highlycontingent on its ability to attract developers to the platform anddrive sales of the corresponding hardware. Android has been widelysuccessful in this respect in large part due to the use of Java asits primary language (The android-scripting project enablesscripting languages to target Dalvik bytecode and recently fullsupport has been added to the Native Development Toolkit (NDK) forC/C.). Google chose Java because of the large community ofdevelopers (at the time of writing, Java is currently #1 in the) and relative ease of use comparedto other mobile languages such as C (Symbian) and Objective-C(iPhone).However, Dalvik is in fact not a true Java platform. Androiduses the Java language and open source Apache Harmony libraries (inaddition to their own) to generate standard classfiles in Javavirtual machine (JVM) bytecode. These classfiles are thentranslated into Dalvik bytecode and stored in a single dex file.This means that not all Java code can be ported directly to Dalvik.Although, in practice much of it can be, since the majority of theJ2SE standard libraries are available, with the notable exceptionsof Swing and AWT.
So you might be asking yourself, why reinvent thewheel? We already have J2SE and J2ME both of which seem adequate.Google’s motivation behind Dalvik is, in fact, based on multiplefactors:Limited ResourcesSmartphone systems are very different from their desktop orlaptop cousins.
There are three main differences that drive designdecisions: battery power, passive cooling and small form factor.Reliance on batteries means that energy is at a premium and must beconserved aggressively. Passive cooling limits the amount of powerthat can be used at any given time to avoid causing the device tobecome unacceptably hot. Lastly, the small form factor places pricepressures on the component sizes of system components and limitsthe amount of feasible battery storage. To make matters worse,battery density growth, that is the amount of energy for a givenvolume, has not kept pace with advancements in mobile hardwaretechnology.This disparity leads to a system that can easily run out ofmemory or deplete the battery, if not managed appropriately. Forexample, a low-end Android phone (Table 1) has a relatively slowARM processor with a clock speed in the range of 500 MHz, withoutfloating point support, a small amount of RAM, often as low as128MB, no operating system swap space and relatively limitedexternal flash storage (usually NAND), and more importantly, amoderately slow read time. Clearly, we cannot simply use the samevirtual machine as a desktop or laptop computer with vastly greatercapability.J2ME’s ProblemsGiven these limited resources, J2ME would seem to be the idealchoice for the platform.
Unfortunately, J2ME is in fact dated withits own share of drawbacks. Many profiles and extensions that areoptional for the platform cause key features of modern smartphoneapps, such as Bluetooth, SIP and 3D graphics for example, to beavailable only on a subset of J2ME phones. This heterogeneity isunattractive to application developers in comparison to platformssuch as iPhone and Android where most features are supported by allphones for a given version of the operating system. Even if thischallenge could be overcome, the Java Specification Request (JSR)process is a lengthy and bureaucratic process required for newfeatures to be included. In contrast, Google, just like Apple withiOS, has complete control and can drive adoption of new features ina faster and more streamlined manner. Lastly, a large part of thereason Java has had limited success in the past on mobile platformsis due to the speed of mobile Java platforms which are not designedto take advantage of today’s smartphone devices. Consequently,rather than using one of the existing Java Virtual Machines, Googleinstead opted to develop a custom clean-room virtual machine oftheir own.Licensing IssuesOracle’s J2SE virtual machine, OpenJDK, is licensed using theGNU Public License version 2 (GPLv2).
However, there is arestriction in the license that shields applications running on thevirtual machine from being “infected” by the GPL because of itscopyleft provision. Copyleft would require applications to have thesame license as the virtual machine itself. In contrast, thisrestriction is not included for the J2ME virtual machine.Cell phone manufacturers would certainly balk at the possibilityof releasing all their application source code, so instead Oraclemakes a good deal of revenue offering their TCK license, for a fee,to avoid this obligation.
Even Apache’s Harmony J2SE VM, whichcould be easily turned into a J2ME virtual machine, has a limitedfield of use restriction to force handset suppliers to purchase aJ2ME license instead of rolling their own. Google asserts thatDalvik avoids this obligation but, Oracle disagrees and has filedlitigation to defend its claim.Open SourceGoogle’s business model for Android is to give it away as anopen source and free platform. Instead of directly generatingrevenue, their goal is to maintain access to the growing smartphonemarket for their services and more importantly, advertising. Withthis goal in mind, Dalvik is licensed using the Apache License 2.0which is very business friendly, because it does not requiremodifications and derivative works to be released under the samelicense.
This allows companies to build and deploy proprietaryproducts using the code for free. Additionally, it permits the codeto be used for free and open source software by the community.SecurityMobile devices contain a significant amount of sensitiveinformation about the user: phone numbers, call records, physicallocation, etc.
Hence, people expect a higher level of security fora smartphone than for a traditional feature phone to protect thisdata. In response to these concernts, Dalvik was designed to takeadvantage of the Linux kernel’s strong security model with each VMinstance running in its own process. This sandboxes processes fromeach other to create a strong barrier between applications.ImplementationNow that we understand the motivation behind creating Dalvik,we’ll discuss how Dalvik custom tailered their design for a mobileplatform by optimizing bytecode filesize, interpreter speed andmemory usage. Also, we will see how the security model impacteddesign of the garbage collector and process initializer,Zygote.Dex FilesizeDalvik’s dex binary files contain all the translated javaclassfiles combined into a single file. The reason each file is notkept separate is to reduce the total storage size. This is possiblebecause each classfile contains constant pools, much of which isredundant to the application and are often the biggest part of aclassfile.
With all these classes together the redundant constantvalues that are shared between the files can be removed and onlyone copy is required. This approach allows the same code to bestored in about the same amount of space that a compressed jar ofthe same classfiles would require. Through consolidation Dalvik isable to increase performance by eliminating the need to decompressthe file (Illustration 1).Interpreter SpeedLast year at the Google I/O conference, the Dalvik teamannounced a just-in-time (JIT) compiler to Dalvik. This additionallows developers to increase the performance of Java code withouthaving to resort to using the Native Development Toolkit (NDK) andrewriting their code in C/C. In contrast to most JIT compilers,the Android team chose to implement code trace optimization insteadof the more common method based optimization.A trace is a sequence of instructions that are executed togetherusually through multiple methods. In an Android game for example,we might have a repaint thread which draws a list of updatedobjects onto a canvas periodically.
This trace would traversemultiple class methods and should be very fast making it a goodcandidate for JIT optimization. As we discussed earlier, Androidruns on a resource constrained system in terms of both memory andCPU power. Consequently the team chose to identify hot traces atruntime to be optimized instead of using more memory to optimizewhole methods. These traces are compiled natively and then areplaced in a translation cache for future use. As pieces of anapplication are translated, execution begins to jump back and forthfrom the translation cache to the interpreter. For hot traces thatare executed back-to-back, execution jumps between the cacheentries and does not return to the interpreter until no translationis available for the required code.
Another design choice forsecurity and simplicity reasons, requires that each individualprocess has its own translation cache.ZygoteZygote enables multiple Dalvik instances to share memory tolimit the memory burden of each running concurrently. As the nameimplies, Zygote’s purpose is to provide a preloaded Android processready for a new application, without incurring the delay ofstarting from scratch. During the initialization of the Zygote,core classes are preloaded into memory to allow even fasterapplication startup. Since each Zygote uses copyon-write for sharedmemory space, much of the memory for each application is reused andthereby places a lighter burden on the limited resources of thedevice.
This only works because these core classes are mostlyread-only and will rarely require more than one version for allapplications. Frank is a Ph.D. Candidate at the University of California, Davis concentrating on Embedded Software and Systems. Since its introduction, he has been doing systems research with Android on automatic low power adaptation techniques. He also owns his own consulting firm, Handy Codeworks (www.handycodeworks.com), which offers training and technical services for Andoid devices. Professionally he enjoys embedded Linux/Android systems hacking and the occasional hardware project. In his spare time he enjoys spending time with his wonderful wife, baby daughter and dog.
He can be reached at fmaker@handycodeworks.com.
Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently.The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimised for minimal memory footprint.The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the.dex format by the included dx tool.Also have a look at for detailed description about DVM.The Dalvik virtual machine is built specifically for Android. It was built to address the battery life and processing power problems, and it is free.We are using Dalvik VM instead of Java Virtual Machine (JVM) because the Java compiler, the Java tools are free, but the JVM is not free, so the Android developers from Google have made their own virtual machine, and made it as free.A virtual machine is necessary because the virtual machine helps in debugging, as a virtual computer so that my applications can run different devices the same wayPictorial Representation. All apk's basic source code is in java language.
When you build this project all.java files get converted to.class now the dx tool of adk converts all.class files to classes.dex file.And this classes.dex file is executed on dalvik virtual machine.For more info on dalvik virtual machine:Dalvik virtual machine is intended to run multiple VMs at a time.So every app runs in its own process, with its own instance of the Dalvik virtual machine as said by @sahilMahajanMj.And this classes.dex file is further optimized to odex file and saved in /dalvik/dalvik-cacheTo know more about odex.If you want to know why DVM for android why not JVM. Dalvik is a virtual machine where every android application runs. Through Dalvik, device is able to run multiple virtual machines through better memory management as Dalvik VMs are register based and hence memory efficientEvery android app runs in its own process, with its own instance of Dalvik VM.First, Java files are connverted to.class file by java compiler.class files are given to 'dx' tool which converts it to.dex format.dex file is given to DVM to produce machine codeMachine code is executed by CPU.apk file contains.dex file in zip format which can be run on Dalvik VMsWhy Dalvik?1. DVM are built for battery life, processing power and its free2.
Android Runtime
We're using DVM instead of JVM as JVM is not freeDalvik VMs gives consistency across all the mobile devices i.e. One application will run across different devices in the same way.