Dalvik virtual machine features and differences with Java virtual machine, dalvik Virtual Machine

Dalvik virtual machine features and differences with Java virtual machine, dalvik Virtual Machine
1. Differences between Dalvik Virtual Machine and Java Virtual Machine

(1) The Java bytecode generated by the Java program after compilation is stored in the class file; the Dalvik virtual machine runs the Dalvik bytecode, And the Dalvik bytecode is converted from the Java bytecode, it is packaged into a DEX executable file.

(2) The Dalvik executable file is smaller, and all class files in the DEX file share the same constant pool.

(3) the Java Virtual Machine and Dalvik virtual machine have different architectures. Java Virtual Machine is based on the stack architecture (requires more command assignment and memory access times). Dalvik virtual machine is based on the register architecture, and data access is directly transferred between registers (much faster than the stack method ).

Example:

public class Hello {public int foo(int a, int b) {return (a + b) * (a - b);}public static void main(String[] argc) {Hello hello = new Hello();System.out.println(hello.foo(5, 3));}}

Use javap-c. Hello to get the Java bytecode of the foo () function:

Public int foo (int, int); Code: 0: iload_1 # int (Operation Type) load (save local variables to the Java stack) the number on the right of the underline indicates the specific local variable for the operation (the index value starts from 0) 1: iload_2 2: iadd # Two int type values are added from the top of the stack and the result is pushed back to the top of the stack 3: iload_1 4: iload_2 5: isub # Two int type values are added and subtracted from the top of the stack, and the result is pushed back to the top of the stack 6: imul # Two int type values are popped up from the top of the stack and multiplied and the result is pushed back to the top of the stack 7: ireturn # returns an int Value

The Instruction Set of the Java Virtual Machine is called a zero-address instruction set. That is, the source and target parameters of the instruction are both implicit, it is passed through a data structure "evaluate stack" provided by the Java Virtual Machine.

Each thread has a PC counter and a Java stack for execution.

(1) PC counter: the offset starting with the current running position distance method is recorded in bytes and only valid for the current method.

(2) Java stack: stores the running status of the thread in frames. Call method> press to stack, return from method> cancel corresponding stack. Each line frame includes the local variable area, evaluate the stack (number of Operation stacks), and other information.

(3) Local Variable Area: storage method parameters and local variables. Parameters are stored from left to right in the source code.

(4) Evaluate Stack: Save the intermediate result of the evaluate and call other method parameters.

Use dexdump.exe to obtain the Dalvik bytecode of the foo () function:

  Virtual methods   -    #0              : (in LHello;)      name          : 'foo'      type          : '(II)I'      access        : 0x0001 (PUBLIC)      code          -      registers     : 5      ins           : 3      outs          : 0      insns size    : 6 16-bit code units000198:                                        |[000198] Hello.foo:(II)I0001a8: 9000 0304                              |0000: add-int v0, v3, v40001ac: 9101 0304                              |0002: sub-int v1, v3, v40001b0: b210                                   |0004: mul-int/2addr v0, v10001b2: 0f00                                   |0005: return v0

When the Dalvik virtual machine runs, it also maintains a PC counter and call stack for each thread. This call stack maintains a register list. The number of registers is in the registers field of the method struct (in this example, 5, is given in the v0-v4. Because the generated code commands are reduced, the program execution speed is faster.

2. Dalvik virtual machine execution Program

Android system architecture (bottom-up): Linux kernel, function libraries, Android runtime, application framework, and applications. The Dalvik virtual machine is used to run Android applications together with some core libraries.

Android startup process:

(1) execute the init process. The init process first initializes the device, then reads the inic. rc file and starts the important external program Zygote in the system.

(2) The Zygote process is the incubator process of all Android processes. After it is started, it first initializes the Dalvik virtual machine, then starts system_server, enters the Zygote mode, and waits for the command through socket.

(3) When an Android Application is executed, the system_server process sends a command to Zygote through socket, after receiving the command, Zygote creates an instance of the Dalvik virtual machine through fork to execute the entry function of the application.

Zygote provides three methods to create a process:

(1) fork (), create a Zygote Process

(2) forkAndSpecialize () to create a non-Zygote Process

(3) forSystemServer (), create a system service process

Davlik virtual machine execution process:

(1) The loadClassFromDex () function loads classes. After each class is successfully parsed, it will have a ClassObject-type Data Structure Stored in the runtime environment.

(2) the virtual machine uses the gDvm. loadedClasses global hash table to store and query all loaded classes.

(3) the bytecode validator uses the dvmVerifyCodeFlow () function to verify the loaded code.

(4) the virtual machine calls the FindClass () function to find and load the main method class, and then calls the dvmInterpret () function to initialize the interpreter and execute the byte code stream.

3. Davlik Virtual Machine JIT (instant compilation)

Mainstream JIT compilation methods include:

(1) method: compile in the unit of function or method.

(2) trace method: compile in the unit of trace. Generally, code is executed sequentially in a function. Most code is divided into several execution paths. Some of the function paths are rarely executed during actual operation, these paths are called "Cold paths", and paths with frequent execution are called "Hot paths ". This method can quickly obtain the "Hot Path" code and use less time and memory for compilation.