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; }

25. Example #1: .Class

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

59. Register promotion

60. Load/store elimination

61. Redundant null-check elimination

62. Loop optimizations

63. Simple loop detection

64. Invariant code motion

66. Thanks Ankit Somani ankitsomani007@gmail.com