Dalvik Vm & Jit
•Download as PPTX, PDF•
4 likes•1,185 views
The document discusses the Dalvik virtual machine (VM) used in Android. It begins by explaining what a VM is and the basic parts that make up a VM. It then discusses the differences between stack-based and register-based VMs, noting that Dalvik uses a register-based architecture. The document explains that Dalvik was chosen for Android because it executes faster than Java VM and uses less memory. It also describes how Java bytecodes are converted to Dalvik bytecodes and discusses optimizations like shared constant pools and just-in-time compilation that improve Dalvik's performance.
![What is VM ? A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Basic Parts: ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Dalvik Vm & Jit
Similar to Dalvik Vm & Jit (20)
Dalvik Vm & Jit
- 1. Dalvik VM & JIT Ankit Somani July 25, 2010
- 3. A stack (optional)
- 4. An execution environment
- 5. A garbage-collected heap
- 6. A constant pool
- 7. A method storage area
- 10. Can run on slow CPU, with little ram & in OS with lesser or even without swap space
- 11. It is optimized to use less space
- 12. The interpreter is simplified for faster execution
- 14. Register code is 25% larger than the corresponding stack code.
- 15. 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.
- 17. Conversion of Java Byte Code to Dalvik Byte Code
- 18. Shared Constant Pool public interface Zapper { public String zap(String s, Object o); } public class Blort implements Zapper { public String zap(String s, Object o) { ...; } } public class ZapUser { public void useZap(Zapper z) { z.zap(...); } }
- 19. Shared Constant Pool (.Class File)
- 20. Shared Constant Pool (.Dex File)
- 22. per-type pools (implicit typing)
- 23. implicit labeling*After the Obfuscation & compression it will be much lesser.
- 24. Example #1: Source public static long sumArray(int[] arr) { long sum = 0; for (inti : arr) { sum += i; } return sum; }
- 26. Example #1: .Dex
- 28. Architecture Comparison
- 29. Supported Libraries Comparison
- 30. Reliability Comparison
- 33. install time, launch time, method invoke time, instruction fetch time
- 34. What to compile
- 35. whole program, shared library, page, method, trace, single instruction
- 36. Android needs a combination that meet the needs of a mobile
- 37. Minimal additional memory usage
- 38. Coexist with Dalvik’s container-based security model
- 39. Quick delivery of performance boost
- 42. Minimizing memory usage critical for mobile devices
- 43. Important to deliver performance boost quickly
- 44. User might give up on new app if we wait too long to JIT
- 45. Leave open the possibility of supplementing with method based JIT
- 46. The two styles can co-exist
- 47. A mobile device looks more like a server when it’s plugged in
- 48. Best of both worlds
- 49. Trace JIT when running on battery
- 52. Useful to think of the JIT as an extension of the interpreter
- 53. Interpreter profiles and triggers trace selection mode when a potential trace head goes hot
- 54. Trace request is built during interpretation
- 55. Trace requests handed off to compiler thread, which compiles and optimizes into native code
- 57. Simple traces - generally 1 to 2 basic blocks long
- 58. Local optimizations
- 61. Redundant null-check elimination
- 64. Invariant code motion
- 66. Thanks Ankit Somani ankitsomani007@gmail.com
Editor's Notes
- Android platform has its own virtual machine dalvik. Every Android application runs in its own process, with its own instance of the Dalvik virtualmachine. Dalvik has been written so that a device can run multiple instances of the VM eciently. The Dalvik VM executes les in the Dalvik Executable (.dex) format which is optimized 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. The Dalvik VM relies on the Linux kernelfor underlying functionalities such as threading and low-level memory management. In this presentation we have discussed virtual machines, specially Dalvik virtual machine in detail and their runtime libraries in comparison with JVM's libraries. The report answers questions, such as why Dalvik was needed and how it overcomes the deficiencies of its counterpart Java virtual machine
- Virtual Machine (VM) is a software environment that can be an emulator, anoperating system or a complete hardware virtualization, that has an implementationof resources without the actual hardware being present.Thus the main idea of virtual machine is to provide an environment that can execute instructions other than those associated with the host environment regardless of the hardware and software
- System VM (also known as hardware virtual machine) and Process VM (also known as application virtual machine) [23]. The categorization is based on their usage and level of correspondence to the associated physical machine. The system VM simulates the complete system hardware stack and supports the execution of complete operating system. On the other hand, Process VM adds up layer over an operating systemwhich is use to simulate the programming environment for the execution of individual process. Virtual Machines are use to share & specify appropriate system resources to the software (could be multiple operating systems or an application); and these softwares are limited to their given resources provided by VM.For many years, in virtual machine architecture, the stack based VMs [23] was the architectural choice due to simplicity of the VM implementation and the size of executables for stack architectures. Registered-based VM [23] can be an attractive alternative to stack-based VM due to the reason that it allows a number of executed VM instructions to be substantially reduced. A study on analysis of dierent VM shows that register-based architecture requires an average of 47% less executed VM instructions than the stack based. On the other hand the register code is 25% largerthan 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 take, on average, a 32.3% less time to execute standard benchmarks.
- Dalvik Executable are complied by Dalvik VM, and are zipped into a single .apk (Android Package) le on the device. The .dex les can be created automatically by translating compiled applications written in the Java programming language.The .dex le is divided into dierent constant pool sections. Each constant pool section is of a particular type. The string_ids section identies all strings included in the .dex le. For example, an explicit coded string in the source code or the name of the method or function. At the bottom it contains a series of class denitions as a single .dex le may contain multiple classes.
- Every Java program (as usual in Java) is compiled to byte code. The Java byte-code is then transformed into Dalvik byte-code with the help of dx tool and stored in .dex le, and that's on what Dalvik performs operations such as verication and optimization.Developers write their own applications in Java and at build time the Java code is converted to a format compatible with Dalvik VM. The Android SDK has a specialized tool called dx tool which converts the .class les of Java to the Dalvik executable les. The dx tool arranges all the Java class les and eliminate all the redundant information that is present in the class les. The initial le loading and parsing procedures that happens again and again are eliminated. Finally, the byte code from the original class les is written into the new form which is executed by the Dalvik VM.In general, a Java .class le contains a number of dierent method signatures used in the code. These signatures are duplicated if referenced in dierent Java classes. In other words, each of these classes references to the methods that takes the same arguments and the same return type. So, each one of these classes will have to include the same method signatures and hence the eorts of parsing the les are duplicated. In addition to this, there is a large number of strings included that labels the internal bits of the class les. On the other hand, when the Java class les are converted to the Dalvik dex les, only a single dex le is created and all of the class les are included in this le. In the dex conversion all of the separate constant pools are collapsed into a single shared constant pool. This way not only is redundant information eliminated but storagespace to store the shared constant pool is also conserved.
- Developers write their own applications in Java and at build time the Java code is converted to a format compatible with Dalvik VM. The Android SDK has a specialized tool called dx tool which converts the .class les of Java to the Dalvik executable les. The dx tool arranges all the Java class les and eliminate all the redundant information that is present in the class les. The initial le loading and parsing procedures that happens again and again are eliminated. Finally, the byte code from the original class les is written into the new form which is executed by the Dalvik VM.In general, a Java .class le contains a number of dierent method signatures used in the code. These signatures are duplicated if referenced in dierent Java classes. In other words, each of these classes references to the methods that takes the same arguments and the same return type. So, each one of these classes will have to include the same method signatures and hence the eorts of parsing the les are duplicated. In addition to this, there is a large number of strings included that labels the internal bits of the class les. On the other hand, when the Java class les are converted to the Dalvik dex les, only a single dex le is created and all of the class les are included in this le. In the dex conversion all of the separate constant pools are collapsed into a single shared constant pool. This way not only is redundant information eliminated but storagespace to store the shared constant pool is also conserved
- At the center of every VM is an interpreter. It fetches dalvik instructions and then interprets and executes it on the host processor. This is an extra stage of interpretation between the CPU. This can be slow. Truth is, the Dalvik interpreter is very fast, and much faster than a traditional Java interpreter. But not everything is in interpretation the whole time. The system has already optimized some processes. In typical use, about a third of operations are being done in the interpreter. This is good enough for most apps, but not perfect. A partial solution is the Native Development Kit, which allows apps to call statically-compiled methods. The other solution is JIT, which avoids runtime interpretation and instead translates byte-code to native code at run time.
- There are a wide variety of JIT styles. The questions to ask are "when should it compile?" and "what stuff should it compile?". What we need is something that uses a very small amount of memory.It also needs to co-exist with dalvik's container based security model.It must also be quick to deliver a performance boost, rather than require the app to run for a while before performance increases.The transition to compiled code and interpretation should also be very smooth.
- There are a wide variety of JIT styles. The questions to ask are "when should it compile?" and "what stuff should it compile?". What we need is something that uses a very small amount of memory.It also needs to co-exist with dalvik's container based security model.It must also be quick to deliver a performance boost, rather than require the app to run for a while before performance increases.The transition to compiled code and interpretation should also be very smooth.
- Techniques:Method vs. Trace Granularity....Method granularity JIT is the most common model. it detects the "hot methods" by profiling the app. Once you identify them, the methods probably have some cold code. You end up compiling code that's not used often.Trace granularity JIT starts interpreting to discover the hot chunks, but not entire methods, but rather chunks of instructions. It creates a straight line trace of code and store them in a cache that can chain multiple chunks. You don't have to respect method call boundaries. You only optimize the hottest of the hot code. It has tight integration with the interpreter. It has a rapid return rate on performance boost once hot chunks are detected; only compiling small chunks that are stitched into the application. Weaknesses are that you don't know what's happening outside the hot chunk, so peaks might be brief; more synchronization with the interpreter is required; and it's more difficult to share translations across processes We found that method JIT provides best optimization possibilities, but trace has best return rate on speed and space. So we chose a trace JIT. The trace provides almost immediate speed returns. In the future, we might use both trace and method jit. For example, when charging and plugged in, the method JIT could take control and perform more profiling in the background.
- We have a curved translation cache for each process. Sharing only within the sandboxes.Local optimizations include load and store elimination if we can, perform redundant null-checking, and some heuristic scheduling. Loop optimizations include simple loop detection and invartiand code motion, plus variable optimzations