Turn Android Dalvik virtual machine First Knowledge

First, let's consider these questions:

What is a Dalvik virtual machine?

What is the difference between a Dalvik vm and a JVM?

What are the new features of the Dalvik VM?

What is the architecture of the Dalvik VM?

First of all, I have to admit that the first question is silly: what is a Dalvik virtual machine? No one has given a definite definition, but it seems that we can get some information from people's descriptions of the Java virtual machines.

A Java Virtual machine (JVM) is a fictional computer that is implemented by simulating various computer functions on a real computer. It has its own perfect hardware architecture (such as processor, stack, register, etc.), also has the corresponding instruction system. The Java Virtual Machine program is used to support programs that are OS-agnostic and that can be run on any system.

Therefore, we may wish to make such a description of the Dalvik virtual machine:

Dalvik virtual machine is the virtual machine of Android program, and it is the base of Java program running in Android. Its instruction set is based on the register schema and performs its unique file format--dex bytecode to accomplish important functions such as Object Lifecycle management, stack management, thread management, security exception management, garbage collection, etc. Its core content is implementation library (libdvm.so), generally implemented by C language. A part of the functionality that relies on the Linux kernel-the threading mechanism, the memory management mechanism, the ability to use memory efficiently, and the high performance on low-speed CPUs. Each Android app will have a standalone Dalvik virtual machine instance on the bottom, and its code can be executed under the virtual machine's interpretation.

The non-JVM that is most closely related to the Dalvik virtual machine, in the Android source code Readme Document, has the phrase: Much of the code under this directory originally came from the Apache Har Mony project, and as such contains the standard Apache header comment. Some of the code is written originally for the Android project ...

The Dalvik VM has a long history with the Apache Harmony project, so the relationship with the JVM is naturally close.

However: Dalvik Vm≠java VM

Dalvik is based on a register, and the JVM is based on a stack

Dalvik performs a unique DEX file format, while the JVM is running the *.class file format.

Advantage: 1. Optimize code in advance at compile time rather than wait until run time

2, the virtual machine is small, the use of space is small, is designed to meet the efficient operation of a variety of virtual machine instances.

3. Chang has been modified to use only 32-bit indexes to simplify the interpreter

The JVM's bytecode is mostly in the form of 0 addresses, which conceptually says the JVM is a stack-based architecture. The main development language for applications on the Google Android platform is Java, which runs Java programs through the Dalvik VMs. In order to correctly implement semantics, many of the Dalvik VMs are designed to be compatible with the JVM, but it uses a register-based architecture whose bytecode is primarily a mixture of two address/three addresses.

Stack-based and register-based architecture, who is faster? Now the actual processor is mostly based on the register architecture, which reflects the fact that the register is closer to the actual processor than the stack-based architecture. However, for VMS, the evaluation stack or register of the source schema may be simulated using the actual machine's memory, 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 a stack-based JVM, because although the 0 address instruction is more compact, the completion requires more Load/store instructions, which also means more command dispatch (instruction Dispatch) Number of times and memory accesses; Access memory is an important bottleneck in execution speed, although each instruction takes up more space, it can complete operations with fewer instructions in general, and less command dispatch and memory accesses.

We can see from the following the comparison between Java bytecode and Dalvid bytecode that corresponds to the same piece of Java code.

Proprietary DEX file format

Many classes are defined in an application,

When the compilation is complete, there will be many corresponding

class file, class file

There will be a lot of redundant information.

One difference in structure between Dex bytecode and standard Java bytecode (class) is that Dex bytecode consolidates multiple files into one, so that, in addition to reducing overall file size, I/O operations also improve the class lookup speed.

It turns out that 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 is mainly for the following aspects:

1. Adjust the byte order (Little_endian) of all fields and not one field in the alignment structure

2. Verifying all classes in the Dex file

3, the optimization of some specific classes, the method of the Operation code optimization

The optimized file size will be increased by 1-4 times the original Dex file.

Odex is designed to further improve performance during operation and further optimize DEX files

An application, a virtual machine instance, a process!!!

Each Android application runs in a Dalvik virtual machine instance, and each virtual machine instance is a separate process space. Communication can be communicated between each process (Ipc,binder mechanism implementation). The threading mechanism of virtual machines, memory allocation and management, mutexes, etc. are all dependent on the underlying operating system.

Different applications run in different process spaces, and when a virtual machine shuts down or unexpectedly aborts, it does not affect other virtual machines, which can protect the application from the most secure and independent operation.

Zygote is the incubator for virtual machine instances. The execution of Zygoteinit.main () in AndroidRuntime.cpp will complete a split, split sub-process that continues to initialize the Java layer's schema, the split-out process is system_server. Whenever a system requires an Android application to execute, Zygote will fork out a child process to execute the application. The benefits of this are obvious: the zygote process is generated at system startup, it completes the initialization of the virtual machine, the loading of the library, the loading and initialization of the pre-set class library, and so on, while the system needs a new virtual machine instance, zygote by replicating itself, the fastest to provide a system. In addition, for some read-only system libraries, all virtual machine instances share a chunk of memory with zygote, saving significant memory overhead.

Turn Android Dalvik virtual machine First Knowledge