Android Virtual Machine Learning summary Dalvik Virtual Machine Introduction

Android Virtual Machine Learning summary Dalvik Virtual Machine Introduction

1. The most significant difference between a Dalvik virtual machine and a Java virtual machine is that they have different file formats and instruction sets. The Dalvik virtual machine uses class files in dex (Dalvik Executable) format, while the Java virtual machine uses class files in class format. A dex file can contain several classes, while a class file only contains one class. Because a dex file can contain several classes, it can save the repeated strings and other constants of each class only once, thus saving space, this method is suitable for mobile phone systems with limited memory and processing speed. In general, uncompress dex files containing the same class are slightly smaller than a compressed jar file.

2. The commands used by the Dalvik virtual machine are based on registers, while those used by the Java Virtual Machine are based on stacks. Stack-based commands are very compact. For example, the commands used by Java virtual machines occupy only one byte. Therefore, they are called bytecode. Register-based commands need to specify the source address and target address, so they need to occupy more space. For example, some commands of the Dalvik Virtual Machine occupy two bytes. The stack-based and register-based instruction sets have their own advantages and disadvantages. Generally, the former requires more commands (mainly load and store commands) to execute the same function ), the latter requires more instruction space. If more commands are required, the CPU usage is required. If more command space is required, the data buffer (d-cache) becomes more efficient.

 

3. In addition, there is another idea that stack-based commands are more portable because they do not make any assumptions about the registers of the target machine. However, the Register-based instruction assumes the registers of the target machine, so it is more conducive to AOT (ahead-of-time) optimization. The so-called AOT is to compile the local machine language program before the interpreter program runs. AOT is essentially a static compilation, which is relative to JIT, that is, the former is compiled before the program runs, and the latter is compiled when the program runs. Runtime compilation means that you can use the runtime information to obtain code that is more optimized for static compilation. It also means that you cannot perform some advanced optimization because the optimization process is too time-consuming. On the other hand, the pre-run compilation does not take up the program running time, so it can optimize the Code regardless of the time cost. Whether AOT or JIT, the ultimate goal is to compile the interpretation language into a local machine language, and the local machine language is executed based on registers. Therefore, to some extent, register-based commands facilitate AOT compilation and optimization.

4. Regardless of the conclusion, the Dalvik virtual machine is doing its best to optimize itself. These measures include:

(1). Collect multiple class files into the same dex file to save space;

(2) Use the read-only memory ing method to load dex files, so that multiple processes can share dex files, saving program loading time;

(3) Adjust the byte order and word alignment Methods in advance to make them more suitable for local machines and improve the instruction execution speed;

(4) Verify bytecode verification in advance to increase the loading speed of the program;

(5) Optimization of bytecode needs to be rewritten in advance.

 

5. Memory Management

 

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

Java Object Heap is used to allocate Java objects, that is, all the objects in the new code are located on Java Object Heap. When the Dalvik virtual machine is started, you can use the-Xms and-Xmx options to specify the minimum and maximum values of Java Object Heap. To prevent the Dalvik Virtual Machine from tuning the Java Object Heap size during the running process, we can use the-Xms and-Xmx options to set the minimum and maximum values to equal values.

 

The maximum value of this Java Object Heap is the maximum memory that can be used by Android application processes. Note that the maximum memory that can be used by Android Application processes is the heap that can be used to allocate Java objects.

In HoneyComb and later versions, Bitmap Memory is directly allocated in Java Object Heap, so that GC management can be directly accepted.

 

Native Heap is the memory allocated by using malloc in Native Code. This part of memory is not limited by the size of Java Object Heap, that is, it can be used freely, of course, it is subject to system restrictions. However, do not abuse Native Heap because it can be used freely. Abuse of Native Heap will cause a sharp reduction in available memory of the system, this causes the system to take radical measures to Kill some processes and supplement the available memory, which will affect the system experience.

6. Garbage Collection

The Dalvik virtual machine can automatically recycle Java objects that are no longer in use, that is, those that are no longer referenced. The automatic garbage collection mechanism frees developers from memory problems, greatly improving the development efficiency and maintainability of the program.

 

In GingerBread and later versions, the garbage collection mechanism used by Dalvik is improved as follows:

(1) Cocurrent, that is, in most cases, the garbage collection thread and other threads are concurrently executed;

(2) Partial collection, that is, only part of garbage may be collected at a time;

(3) The program suspension time caused by a garbage collection is usually less than 5 ms.

 

 

7. Process and thread management

Generally, the processes and threads of a virtual machine correspond to the processes and threads of the Local Operating System of the target machine. The advantage of this is that the local operating system can schedule processes and threads. Process and thread scheduling are the core modules of the operating system, and their implementation is very complicated, especially considering the situation of multiple cores, there is no need to provide a process and thread library in the virtual machine.

 

The Dalvik virtual machine runs on the Linux operating system. We know that Linux does not have a pure thread concept. As long as two processes share the same address space, they can be considered as two threads of the same process. The Linux operating system provides two fork and clone calls, the former is used to create processes, and the latter is used to create threads.

 

The Android application process has two major features.

 

The first feature is that every Android application process has a Dalvik Virtual Machine instance. The advantage of this is that Android Application processes do not affect each other. That is to say, the unexpected suspension of an Android application process does not affect the normal operation of other Android application processes.

 

The second feature is that every Android application process is fork from a process called Zygote. The Zygote process is started by the init process, that is, when the system starts. 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.

 

Abstract: http://blog.csdn.net/luoshengyang/article/details/8852432