Dalvik virtual machine vs. JVM

Dalvik virtual machines and Java virtual machines have many similar features, both support Gc,jit,jni and so on. The main difference is that the file format and instruction set are different, and the characteristics of the two are compared and discussed.

Difference1: File format

The Dalvik virtual machine class file is in DEX format, and the JVM's class file is in class format. The difference is that we are familiar with only one class in a class bytecode file, and the Dex file can contain multiple classes. The advantage is that repeated constants and strings in multiple classes will only save one copy, saving some space and being more suitable for running on the phone.

Difference2: Instruction Set

The instruction set of the Dalvik is based on a register, and the instruction set of the JVM is based on the stack. The difference is that the register-based instruction is addressed in the Register, faster but with a long instruction length, and the stack-based instruction set is shorter but consumes more CPU time. The comparison is similar to that of CISC and RISC. In terms of portability, it is clear that stack-based instruction sets are more portable and do not optimize for the registers of target machines. While the register-based instruction set can be re-run for the target machine before the register to optimize the program, this optimization is in the compilation process optimization, not similar to the JIT in the process of dynamic optimization, but the ultimate goal is to convert the program into the local machine language.

The following is a discussion of 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 broadly divided into three parts: the Java Object heap, the Bitmap memory, and the native heap.

The Java object heap is used to store Java objects, and different handset manufacturers have different settings for their size, and can get their maximum value from Activitymanager's Getmemoryclass, which is the maximum memory that Android apps can use.

Bitmap memory is used for storing and processing pictures. Prior to Android3.0, Bitmap memory was part of the native heap, and its size was counted into the Java object Heap, where the memory of Bitmap and other Java objects did not exceed the maximum value of Joh above. After Android3.0, the Bitmap memory is distributed directly in the Joh, facilitating GC.

The Native heap is the memory allocated for the Local machine language request.

Garbage Collection

In previous versions of Android2.3, the garbage collection policy for Dalvik virtual machines was as follows:

• When the garbage collection thread executes, the other threads stop to collect the total garbage at a time, and the result is that the program abort time of the garbage collection is usually greater than 100ms.
• After Android2.3, the garbage collection thread is executed concurrently with other threads, which may collect only a portion of the garbage at a time, making the program abort times of a garbage collection significantly lower, usually less than 5ms.

JIT

JIT is compiled in the process of running the program, the repeated calls to the local machine code to save the code, the process is executed dynamically at runtime, relative to the program compile-time optimization, the JIT will occupy the program run time. The Android2.2 only started to support JNI.

Local Call

The Java program runs on the virtual machine and requires that the program be translated into the instructions of the target machine, and some functions need to be done by invoking the target machine's operating system interface. Native calls from Java can help us call functions in Java code and c\c++ code. Android provides the NDK to help us achieve 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 at runtime.
• Each Android application process is forked out by a zygote process. The zygote process is created by the initialization process. When the zygote process starts, it creates a virtual machine instance and loads all of the Java core libraries in this virtual machine instance. Whenever the zygote process needs to create an Android application process, it is implemented by copying itself, that is, by the fork system call. These forked Android application processes, on the one hand, replicate the virtual machine instances in the zygote process and share the same set of Java core Libraries with the zygote process. This not only makes the process of Android applications fast, but also saves memory space because all Android application processes share the same set of Java core libraries.

Dalvik virtual machine vs. JVM