Android Core: JVM, DVM, ART, JIT, AOT

It’s really important to understand that how android app works and what components are used to make android device work.

So in this guide, I’m going to answer the following questions

• Why Android use Vitual Machine
• What is JVM and DVM
• JVM vs DVM
• Why Android OS used DVM instead of JVM
• Why Android depreciated DVM and started to use ART
• Why Android Reintroducing JIT with ART
• JIT vs AOT

Why Android use Virtual Machine?

As we are going to know why android use virtual machine. Before that we should a clear idea on Virtual Machine (VM)

What is Virtual Machine (VM)

Virtual Machine is an abstraction over the native machine backed by the resources of the native machine. It’s job is to convert language specific code to a format compatible to run on the Virtual Machine. Virtual Machine enables the same code to be run on multiple platform independent of the underlying hardware.

For example: the JVM runs java bytecode and produces same output on multiple platforms.

Android also makes use of a virtual machine to run the APK files. Below are the advantages:

• The application code is isolated from the core OS. So even if any code contains some malicious code won’t directly affect the system files. It makes the Android OS more stable and reliable.
• It provides cross compatibility or platform independency. It meaning even if an app is compiled on platform such as a PC, it can still be executed on the mobile platform using the virtual machine.

Java Virtual Machine | JVM

• To maintain the platform independency of the code, JAVA developed JVM i.e. Java Virtual Machine
• JVM is platform dependent and different implementations are available for specific platforms.
• JVM uses JIT compiler.
• Java bytecode can be run on any machine capable of running JVM.
• In JVM, The Java compiler converts the .java files into .class files, which is called bytecode. For example: If we have a Hello.java class and when we run this class file then javac compiler/Java Compiler turns this source code to Hello.class file which is bytecode. Which means javac compiler does not convert Java code directly to machine code like other compiler does.
• This bytecode is given to the JVM which converts it into machine code.

As you can see from the image above, once you have .class file ready then you can give this file to any platform and it will convert it to native machine code.

Dalvik Virtual Machine | DVM

What are you thinking ? as java code execution works by JVM and android uses java. So Android also use JVM?. It would be but though JVM is high performance and provides excellent memory management, it needs to be optimized for low-powered handheld devices as well. Thats why another Virtual machine was designed specifically for mobile devices and that is Delvik Virtual Machine (DVM).

• DVM is stands for ‘Delvik Virtual Machine’
• DVM (Dalvik Virtual Machine) was created by Dan Bornstein and his team, keeping in mind only the constraints of a mobile device.
• It was a purpose specific VM and was strictly created for mobile devices.
• Similarly to JVM, it also uses the JIT compiler.
• Since everything in mobiles is very limited whether it would be a battery life, processing and memory etc. It had been optimised so that it can fit in with low-powered devices.
• In DVM, everything is same as JVM except last two steps here. The Dex compiler converts the class files into the .dex file that run on the Dalvik VM. Multiple class files are converted into one dex file.

Note: dexopt tool which is a part of the DVM converts the dex file into .odex file format.

JVM vs DVM

• JVM is stack based but DVM is register based which is designed to run on low memory.
• JVM uses java byte code and runs ‘.class’ file having JIT (Just in Time) where DVM uses its own byte code and runs ‘.dex’ file.
• In JVM, single instance is of JVM is shared with multiple applications where DVM has been designed so that the device can run multiple instance of VM efficiently. Applications are given their own instance.
• JVM support multiple operating system where DVM supports Android operating system only.
• In JVM, the executable is JAR where in DVM the executable is APK.

Why Android OS uses DVM instead of JVM?

There are couple of reasons why Google choose DVM over JVM, so let’s understand each one of them one by one.

• One of the main reasons of using DVM in android is DVM takes less memory, runs and loads faster compared to JVM
• Though JVM is free, it was under GPL license, which is not good for Android as most the Android is under Apache license.
• JVM was designed for desktops and it is too heavy for embedded devices.

Why Android depreciated DVM and started to use ART ?

There were some drawbacks to use DVM. In Dalvik runtime , an app is compiled every time when an app is launched. This leads to excessive CPU and memory usage and also reduces the battery life. Thats why from Android 4.4 (KitKat) ART was introduced and from Android 5.0 (Lollipop) it has completely replaced Dalvik.

• ART stands for ‘Android Run-Time’
• ART uses AOT (Ahead-of-Time) compilation

In ART, During the app’s installation phase, AOT ( Ahead-of-Time) statically translates the DEX bytecode into machine code and stores in the device’s storage. This is a one-time event and happens only when the app is installed on the device. This leads to better battery life and great performance. So there’s no need for JIT compilation, and the code executes much faster.

The most significant change from Dalvik to ART is that Dalvik is based on Just-in-Time (JIT) compilation, while ART is based on Ahead-of-Time (AOT) compilation.

• AOT uses dex2oat tool to compile .dex files and generates a compiled app to be run on the target device
• Garbage collection is one of the main reasons for a poor UX, poor responsiveness, and ultimately bad reviews. In the Dalvik days, GC used to have two passes over the heap, which led to poor UXs. This situation is improved in ART, as only one pass over the heap to consolidate the memory is required.

Benefits of ART over DVM

• Apps run faster as DEX bytecode translation done only during installation.
• Reduced startup time of applications as native code is directly executed.
• Improved battery performance as power utilized to interpreted byte codes line by line is saved.
• Improved garbage collector
• Improved developer tool.

Reintroducing of JIT with ART

Though ART improved app performance, there were some drawbacks of ART.

Drawbacks of ART

• App Installation takes more time because of DEX bytecodes conversion into machine code during installation.
• As the native machine code generated on installation is stored in internal storage, more internal storage is required.

To tackle these problems such as initial installation time and memory from Android Nougat JIT (Just In Time ) Compilation was reintroduced with code profiling along with AOT, and an interpreter in the ART thus making it hybrid. Using the Hybrid Runtime, there won’t be any compilation during install, and applications can be started right away, the bytecode is interpreted.
Now with ART and the new JIT the application installation is faster. The new JIT constantly does profiling and improves applications as they run.

JIT vs AOT

• JIT (Just In Time) compiler compiles source code into machine code during runtime (This means that each time your app is run, a part of a .dex file is converted dynamically ) where AOT Compiles the source code before execution.
• JVM and DVM uses JIT where ART uses AOT Compliler

Be sure to give claps if you find this article helpful. Happy Coding !