First knowledge of Android Dalvik Virtual Machine

First, let's think about the following questions:

What is a Dalvik Virtual Machine?

What is the difference between Dalvik Vm and JVM?

What are the new features of Dalvik VM?

What is the architecture of Dalvik VM?

 

 

First, I have to admit that the first question is silly: What is a Dalvik Virtual Machine? No one has given a clear definition, but we seem to be able to get some information from people's descriptions of Java virtual machines.

 

The Java Virtual Machine (JVM) is a fictitious computer that simulates various computer functions on the actual computer. It has its own complete hardware architecture (such as processor, stack, register, etc.) and corresponding command system. The "Java Virtual Machine" program is used to support programs that are not related to the operating system and can run in any system.

 

Therefore, we may describe the Dalvik virtual machine as follows:

Dalvik virtual machine is the virtual machine of Android programs, and is the basis for running Java programs in Android. Its instruction set is based on the register architecture and executes its unique file format, Dex bytecode, to complete important functions such as object lifecycle management, stack management, thread management, security exception management, and garbage collection. Its core content is the implementation Library (libdvm. So), which is generally implemented in C language. Depends on some features of the Linux kernel-thread mechanism and memory management mechanism, which can efficiently use the memory and deliver high performance on low-speed CPUs. Each Android Application corresponds to an independent Dalvik Virtual Machine instance at the underlying layer, and its code can be executed under the explanation of the virtual machine.

 

Non-JVM is the most closely related to Dalvik virtual machines. In the README file of Android source code, there is a saying: much of the code under this directory originally came from the Apache Harmony project, and as such contains the standard Apache header comment. some of the Code was written originally for the android project...

Dalvik VM has a long history with Apache harmony. Therefore, the relationship with JVM is naturally close.

 

 

 

 

However: Dalvik Vm = Java VM

Dalvik is based on registers, while JVM is based on stacks.

Dalvik runs the unique Dex file format, while JVM runs the *. Class file format.

Advantages: 1. Optimize the code in advance during compilation instead of waiting for the runtime

2. The virtual machine is small and the space used is small. It is designed to efficiently run multiple virtual machine instances.

3. The constant pool has been changed to a 32-bit index only to simplify the interpreter.

 

 

JVM bytecode is mainly in the form of zero address. In terms of concept, JVM is a stack-based architecture. The main development language of applications on the Google Android platform is Java, where the Dalvik VM runs Java programs. Many of Dalvik VM's designs take into account the compatibility with JVM for correct semantic implementation, but it uses a register-based architecture, the bytecode is a mixture of two addresses and three addresses.

Who is faster Based on Stack and register-based architecture? Currently, most of the actual processors are register-based architectures, which show that the register-based architecture is closer to the actual processor than the stack-based architecture. However, for the VM, the evaluation stack or register of the source architecture may be simulated using the memory of the actual machine, so the performance characteristics are different from the actual hardware. It is generally considered that the Dalvik VM Based on the register architecture is more efficient than the stack-based JVM, because although the zero-address command is more compact, more load/store commands are required to complete the operation, it also means more commands (Instruction dispatch) and memory access times. Access to memory is an important bottleneck of execution speed, although two or three-address commands occupy a large amount of space, in general, they can be executed with fewer commands, with fewer command assignment and memory access times.

We can clearly see the comparison between Java bytecode and dalvid bytecode corresponding to the same Java code section below.

 

 

 

 

Proprietary Dex File Format

Many classes are defined in an application,

After compilation, there will be a lot of corresponding

Class file, class file

There will be a lot of redundant information.

The difference between DEX bytecode and standard Java bytecode (class) Is that Dex bytecode integrates multiple files into one. In this way, in addition to reducing the overall file size, i/O operations also increase the speed of searching classes.

The constant pool in each class file is now managed by a constant pool in the DEX file.

The Dex file can be further optimized. The optimization mainly targets the following aspects:

1. Adjust the byte order of all fields (little_endian) and none of the fields in the alignment structure

2. Verify all classes in the DEX File

3. Optimize some specific classes and the operation codes in the methods

The optimized file size will increase, which should be 1-4 times that of the original Dex file.

Odex is used to further improve the performance of DEX files during operation.

 

 

 

 

One application, one virtual machine instance, and one process !!!

Each Android Application runs in a Dalvik Virtual Machine instance, and each virtual machine instance is an independent process space. Each process can communicate with each other (implemented by the IPC and Binder Mechanism ). The thread mechanism, memory allocation and management, and mutex of virtual machines depend on the underlying operating system.

Different applications run in different process spaces. When a virtual machine is shut down or unexpectedly aborted, it does not affect other virtual machines. This maximizes application security and independent operation.

Zygote is the incubator for Virtual Machine instances. In androidruntime. CPP, the execution of zygoteinit. Main () completes a split. The split child process continues to initialize the Java layer architecture. The split process is system_server. Every time the system requires an Android Application to be executed, zygote will fork a sub-process to execute the application. The advantages of doing so are obvious: the zygote process is generated when the system starts. It completes VM initialization, Library Loading, loading and initialization of Preset class libraries, and so on, when the system needs a new Virtual Machine instance, zygote provides a system in the fastest way by copying itself. In addition, for some read-only system libraries, All VM instances share a memory area with zygote, greatly saving the memory overhead.