Comparison between Dalvik Virtual Machine and JVM

Comparison between Dalvik Virtual Machine and JVM

The Dalvik virtual machine has many similar features as the Java Virtual Machine, including GC, JIT, and JNI. The main difference is that the file format and instruction set are different, and the features of the two are compared and discussed below.

Difference1: File Format

Dalvik's virtual machine files use the dex format, while JVM class files use the class format. The difference is that the familiar class bytecode file only contains one class, And the dex file can contain multiple classes. The advantage is that repeated constants and strings in multiple classes only save one copy, which saves space to some extent and is more suitable for running on mobile phones.

Difference2: Instruction Set

The Dalvik instruction set is based on registers, while the JVM instruction set is based on stacks. The difference is that register-based commands are addressable in registers, which is faster but longer than the instruction length. stack-based instruction sets are shorter, but consume more CPU time. The comparison is similar to the comparison between CISC and RISC. In terms of portability, it is obvious that the stack-based instruction set is more portable, and it does not optimize the registers of the target machine. The memory-based instruction set can be used to optimize the program for the registers of the target machine before the program runs. This optimization is in the compilation process and is not similar to the dynamic optimization of JIT in the running process, however, the ultimate goal is to convert programs into local machine languages.

The following describes memory management, JIT, garbage collection, JIT, JNI, and process and thread management for Dalvik virtual machines.

Memory Management

The Memory of the Dalvik virtual machine can be divided into three parts: Java Object Heap, Bitmap Memory, and Native Heap.

Java Object Heap is used to store Java objects. Different mobile phone manufacturers have different settings for the size. You can use getMemoryClass of ActivityManager to obtain the maximum value, which is the maximum memory available for Android applications.

Bitmap Memory is used to store and process images. Before Android, Bitmap Memory was part of Native Heap and its size was included in Java Object Heap. That is, the Memory occupied by bitmap and other java objects cannot exceed the maximum value of JOH above. After Android3.0, Bitmap Memory is directly allocated in JOH to facilitate GC.

Native Heap is the memory allocated by the local machine language.

Garbage Collection

In versions earlier than Android2.3, the garbage collection policy of the Dalvik virtual machine is as follows:

When the garbage collection thread is executing, all other threads stop, so as to collect full garbage at a time, the result is that the program suspension time caused by a garbage collection usually exceeds 100 ms.

After Android2.3, the garbage collection thread and other threads execute concurrently, and only part of the garbage is collected at a time, which greatly reduces the program suspension time caused by a garbage collection, usually less than 5 ms.

JIT

JIT is compiled during the program running process, and the code that is repeatedly called is converted to the local machine code for saving. This process is dynamically executed during the runtime. Compared with the optimization during program compilation, JIT takes up the running time. JNI is supported only after Android2.2.

Local call

Java programs run on virtual machines. You need to translate the program into the commands of the target machine for execution. Some functions need to be completed by calling the operating system interface of the target machine. Java local calls can help us call functions in Java code and C \ C ++ code. Android provides NDK to help us implement JNI.

Thread Management

The Android process has two main features:

Each Android APP process has a Dalvik Virtual Machine instance, which ensures that multiple apps do not affect each other during running.

Every Android application process is fork from a Zygote process. The Zygote process is created by the initialization process. When the Zygote process is started, a virtual machine instance is created and all the Java core libraries are loaded on the Virtual Machine instance. Every time a Zygote process needs to create an Android application process, it is implemented by copying itself, that is, it is called by the fork system. These fork Android Application processes replicate Virtual Machine instances in the Zygote process, and share the same Java core library with the Zygote process. In this way, not only does the process of creating Android applications quickly, but also saves memory space because all Android Application processes share the same Java core library.

This article permanently updates the link address: