Dalvik Vm & Jit

3,264 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,264
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
123
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 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 
  • Dalvik Vm & Jit

    1. 1. Dalvik VM & JIT<br />Ankit Somani <br />July 25, 2010<br />
    2. 2. What is VM ? <br />A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine.<br />Basic Parts:<br /><ul><li> A set of registers
    3. 3. A stack (optional)
    4. 4. An execution environment
    5. 5. A garbage-collected heap
    6. 6. A constant pool
    7. 7. A method storage area
    8. 8. An instruction set</li></li></ul><li> Types of VM ? <br /><ul><li> Based on its Working &Functionality : </li></ul>1. System Virtual Machine (supports execution of a complete operating system)<br />2. Process Virtual Machine (supports execution of a single process)<br /><ul><li> Based on its architecture :</li></ul>1. Stack based VM (uses instructions to load in a stack for execution)<br />2. Register based VM (uses instructions to be encoded in source and destination<br />registers)<br />
    9. 9. Dalvik Virtual Machine<br /><ul><li>Dalvik architecture is register based
    10. 10. Can run on slow CPU, with little ram & in OS with lesser or even without swap space
    11. 11. It is optimized to use less space
    12. 12. The interpreter is simplified for faster execution
    13. 13. It executes its own Dalvik byte code rather than Java byte code</li></li></ul><li> Why android choose Dalvik?<br /><ul><li>Dalvik (Register based) take average 47 % less executed VM instruction then JVM (Stack based).
    14. 14. Register code is 25% larger than the corresponding stack code.
    15. 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.
    16. 16. Some Marketing Reasons too.</li></li></ul><li> .Dex file anatomy<br />
    17. 17. Conversion of Java Byte Code to Dalvik Byte Code<br />
    18. 18. Shared Constant Pool<br />public interface Zapper {<br /> public String zap(String s, Object o);<br />}<br />public class Blort implements Zapper {<br /> public String zap(String s, Object o) {<br /> ...;<br /> }<br />}<br />public class ZapUser {<br /> public void useZap(Zapper z) {<br /> z.zap(...);<br /> }<br />}<br />
    19. 19. Shared Constant Pool (.Class File)<br />
    20. 20. Shared Constant Pool (.Dex File)<br />
    21. 21. Shared Constant Pool (Memory Saved Via)<br /><ul><li> minimal repetition
    22. 22. per-type pools (implicit typing)
    23. 23. implicit labeling</li></ul>*After the Obfuscation & compression it will be much lesser.<br />
    24. 24. Example #1: Source<br />public static long sumArray(int[] arr) {<br /> long sum = 0;<br /> for (inti : arr) {<br /> sum += i;<br /> }<br /> return sum;<br />}<br />
    25. 25. Example #1: .Class<br />
    26. 26. Example #1: .Dex<br />
    27. 27. Comparison b/w Dalvik VM versus JVM<br /><ul><li> Memory Usage Comparison
    28. 28. Architecture Comparison
    29. 29. Supported Libraries Comparison
    30. 30. Reliability Comparison
    31. 31. Multiple instance and JIT Comparison</li></li></ul><li> JIT (Just in Time) Compilation<br /><ul><li> What is JIT ?</li></ul>Just-in-time compilation (JIT), also known as dynamic translation, is a technique for improving the runtime performance of a computer program.<br />A hybrid approach, with translation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation<br />
    32. 32. JIT Types<br /><ul><li>When to compile
    33. 33. install time, launch time, method invoke time, instruction fetch time
    34. 34. What to compile
    35. 35. whole program, shared library, page, method, trace, single instruction
    36. 36. Android needs a combination that meet the needs of a mobile
    37. 37. Minimal additional memory usage
    38. 38. Coexist with Dalvik’s container-based security model
    39. 39. Quick delivery of performance boost
    40. 40. Smooth transition between interpretation & compiled code</li></li></ul><li>Android system_server example<br />
    41. 41. Trace JIT <br /><ul><li> Trace : String of Instructions
    42. 42. Minimizing memory usage critical for mobile devices
    43. 43. Important to deliver performance boost quickly
    44. 44. User might give up on new app if we wait too long to JIT
    45. 45. Leave open the possibility of supplementing with method based JIT
    46. 46. The two styles can co-exist
    47. 47. A mobile device looks more like a server when it’s plugged in
    48. 48. Best of both worlds
    49. 49. Trace JIT when running on battery
    50. 50. Method JIT in background while charging</li></li></ul><li> Dalvik Trace JIT Flow<br />
    51. 51. Dalvik JIT v1.0 Overview<br /><ul><li> Tight integration with interpreter
    52. 52. Useful to think of the JIT as an extension of the interpreter
    53. 53. Interpreter profiles and triggers trace selection mode when a potential trace head goes hot
    54. 54. Trace request is built during interpretation
    55. 55. Trace requests handed off to compiler thread, which compiles and optimizes into native code
    56. 56. Compiled traces chained together in translation cache</li></li></ul><li>Dalvik JIT v1.0 Features<br /><ul><li> Per-process translation caches (sharing only within security sandboxes)
    57. 57. Simple traces - generally 1 to 2 basic blocks long
    58. 58. Local optimizations
    59. 59. Register promotion
    60. 60. Load/store elimination
    61. 61. Redundant null-check elimination
    62. 62. Loop optimizations
    63. 63. Simple loop detection
    64. 64. Invariant code motion
    65. 65. Induction variable optimization</li></li></ul><li>Questions ?<br />
    66. 66. Thanks<br />Ankit Somani <br />ankitsomani007@gmail.com<br />

    ×