Virtual Machine in Android: Everything you need to know
A virtual machine is based on computer architectures to provide functionality of a computer.
There are 2 main types of Virtual Machine (VM):
- System virtual machines (full virtualization VMs) provide a substitute for a real machine.
- Process virtual machines are designed to execute computer programs in a platform-independent environment.
Java Virtual Machine
Java Virtual Machine (JVM) is a Process virtual machine.
Follow “write once, run anywhere” principle, JVM allows programs — written in Java/Kotlin — to run on any device or operating system.
How it works?
IDEs — like IntelliJ / Android Studio — use Java Compiler (
javac) to compile Java code (
.java) into Java bytecode (
Then on runtime environments (Web, PC, Android), JVM translates it into machine specs instruction set that this environment can understand.
- Start JVM.
- Start main thread. Load
.classinto memory using Classloader.
- Verify bytecode is valid and not violate Java’s security restrictions.
- Translate bytecode into machine instructions and execute them.
- Unload classes. Terminate main thread.
- Shutdown JVM.
Note that: It’s possible to compile Java code to native code ahead-of-time, then run. And it’s also possible to interpret Java code directly.
Android is an open source, Linux-based software stack created for a wide array of devices and form factors. For example, the Android Runtime (ART) relies on the Linux kernel for underlying functionalities: networking, multi-threading and low-level memory management,..
Why Android use virtual machine?
There are many reason that Google engineers decide to use Android with VM, but two main reason is:
- Security: In theory, app code is totally isolated by the VM and cannot even “see” the host OS. So app code that contains malware cannot affect system directly, make app and system more robust and reliable.
- Platform independent: Android platform can run on different devices with different architectures (ARM, MIPs, x86). To abstract out the need to compile binaries for each architecture, VM comes into play.
Dalvik Virtual Machine
Dalvik Virtual Machine (DVM) is a Process virtual machine for Android.
DVM is a virtual machine that optimized for mobile environment (memory, battery life, performance,..)
Dalvik EXecutable (
.dex) is Dalvik bytecode which translated from Java bytecode using dx tool (replaced by D8 tool since API 28). This format was designed for systems that have constrained memory and processor speed.
Multiple classes are included in a single
Compare with Java VM
The DVM was built specifically for Android, to address the battery life, processing speed. Moreover, the Java tools are free but the JVM is not, so Google engineers made their own VM and made it as free.
Unlike JVM, which are simple stack machines, the DVM uses a register-based — which requires fewer instructions, fewer code units, avoid unnecessary memory access — resulting in better performance code.
Android Runtime (ART) is the managed runtime used by apps and system services on Android. Replacing the predecessor Dalvik, ART performs the translation of the app’s bytecode into native instructions that are later executed by the device’s runtime environment.
The ART is written to run multiple VMs on low-memory devices. To maintain backward compatibility, ART also uses the same input bytecode as Dalvik — the standard Dalvik EXecutable (
.dex) files — which also designed for Android to minimize memory footprint.
From Android 5.0, each app runs in its own process, with its own instance of ART. But prior to this, it use Dalvik. If your app runs well on ART, then it should work on Dalvik as well, but the reverse may not true.
Just-In-Time vs Ahead-Of-Time
Just-In-Time (JIT) added in Android 2.2. It dynamically compiles bytecode into native machine code at run-time to make app runs faster. It does all this while app is running, and that’s where the “Just-In-Time” comes from.
Ahead-Of-Time (AOT) added in Android 4.4. It statically compiles bytecode into machine code at install-time — using on-device dex2oat tool — and stores data in the device’s storage, to improve run-time performance.
Compare with Dalvik VM
Dalvik is a JIT compilation based engine.
The ART includes a JIT compiler (with code profiling). The JIT compiler complements new AOT compiler and improves runtime performance, speed up apps and system updates.
Furthermore, ART has many more advantage:
- Optimized garbage collector: one GC pause instead of two.
- Loop optimizations: Bounds check, Induction variable is eliminated.
- Faster native calls using
- Improve battery life.
- Reduce startup time as native code is directly executed.
- Faster runtime performance because AOT compile at install-time.
- From API 28, convert APK’s DEX files to more compact machine code.
- Better debugging support (dedicated sampling profiler, detailed exceptions reporting, and ability to set watchpoints to specific fields).
Optimized Garbage Collector
Garbage Collector (GC) can impact app’s performance with “stop-the-world” events, which resulting in frozen frames, poor UI responsiveness. The default GC plan is the CMS (concurrent mark sweep).
The ART improves GC in several ways:
- The number of pauses is reduced from 2 to 1 compared to Dalvik. Dalvik’s first pause — which mostly root Marking — is done concurrently in ART by getting the threads to mark their own roots.
- Parallelized processing in the second pause (before Sweeping phase).
- Increased GC throughput enabled by the sticky CMS collector.
- Reduce total time when clean up recently-allocated, short-lived objects.
- Performs heap compaction — when app changes process state to background or cached — to reduce background memory usage.
Before Android 5.0 (API 21), Android use Dalvik Virtual Machine (DVM) — a Process virtual machine — that optimized for mobile environment (memory, battery life, performance,..).
After that, each Android app runs in its own process and with its own instance of the Android Runtime (ART) — an app runtime environment used by Android OS. Replacing Dalvik, ART performs the translation of the app’s bytecode into native instructions that are later executed by the device’s runtime environment.