Java virtual machine, Dalvik virtual machine, and ART Virtual Machine
1. What is JVM? JVM is essentially a piece of software. It is a software abstraction of computer hardware, where Java programs can be run. After compilation, JAVA generates JVM bytecode similar to assembly languages, different from the compilation language produced after C language compilation, C compiled assembly language runs directly on hardware, but the bytecode generated after JAVA compilation runs on JVM, the JAVA program can run only when the JVM translates bytecode into machine commands. JVM runs on the operating system, shielding the underlying implementation differences, and thus having the platform independence and Write Once Run Anywhere that JAVA boast. There are dozens of specific virtual machines implemented according to JVM specifications. Mainstream JVM, including Hotspot and Jikes RVM, are all written in C/C ++ and assembly, each JRE is compiled for each platform. Therefore, the download of JRE (JVM, Java core class library, and support files) is platform-independent, and the role of JVM is platform-independent. the bytecode in the class is translated into platform-related machine codes for cross-platform implementation. 2. What is DVM? What is the difference with JVM? JVM is a Java Virtual Machine, while DVM is a Dalvik Virtual Machine. It is a Virtual Machine used in Android. All Android programs run in the Android system process, and each process corresponds to a Dalvik Virtual Machine instance. They provide object lifecycle management, stack management, thread management, security and exception management, and garbage collection among other important functions, each having a complete command system, the following briefly compares the differences between the two virtual machines.① JAVA bytecode is run on the JAVA Virtual Machine, and Dalvik bytecode is run on the Dalvik Virtual MachineAfter the JAVA program is compiled, the JAVA bytecode is generated and stored in the class file. JVM can run the program by decoding the content in the class file. DVM runs Dalvik bytecode. All Dalvik bytecode is converted from JAVA bytecode and packaged into a DEX (Dalvik Executable) Executable file, DVM executes these bytecode by interpreting the DEX file.② Dalvik executable files are smaller in sizeThe following is the class file structure expressed in the C data structure in the JVM specification. After the class file is loaded into the memory by the VM, the class file contains multiple different method signatures, if Class A files reference methods in Class B files, the method signature will also be copied to the Class A file (this signature will be used to link to the Class B method in the connection phase of the VM loading class), that is, multiple different classes contain the same method signature at the same time. Similarly, a large number of string constants are also used repeatedly in multiple class files. Such redundant information directly increases the file size, when JVM loads the description class data from the class file to the memory, it needs to verify, convert, parse, and initialize the data to form a JAVA type that can be directly used by the virtual machine, A large amount of redundant information will seriously affect the efficiency of parsing files on virtual machines. To reduce the volume of execution files, Android uses the Dalvik virtual machine. The SDK has a dx tool to convert JAVA bytecode to Dalvik bytecode, And the dx tool re-arranges JAVA-class files, break down the constant pools in all JAVA class files, eliminate redundant information, and recombine to form a constant pool. All class files share the same constant pool, make the same string and constant appear only once in the DEX file, thus reducing the file size. Shows the conversion process of the dx tool and the structure of the DEX file.③ JVM is stack-based and DVM is register-based.The Java Virtual Machine is based on the stack structure. During running, the virtual machine needs to read and write data from the stack frequently. This process requires more command assignment and memory access times, which will consume a lot of CPU time. The Dalvik virtual machine is based on the register architecture. Data Access is directly transmitted between registers. Such access is much faster than stack-based access.
public class Hello { public int foo(int a, int b) { return (a + b) * (a - b); } public static void main(String[] args) { Hello t = new Hello(); System.out.print(t.foo(5, 3)); }}
Take the foo method in this Code as an example. After compiling it into a class file, decompile the class file to view the JAVA bytecode:
Code: 0: iload_1 1: iload_2 2: iadd 3: iload_1 4: iload_2 5: isub 6: imul 7: ireturn
For the foo method of the same Code, compile and generate the dex file and view the Dalvik bytecode:
0000: add-int v0, v3, v4 0002: sub-int v1, v3, v4 0004: mul-int/2addr v0, v1 0005: return v0
Compared with the above bytecode, Code commands are reduced, and the execution speed is certainly faster. Compare the two virtual machines to execute their own bytecode. 3. What is the ART virtual machine? What is the difference between it and JVM/DVM? First, we understand the JIT (Just In Time, instant compilation technology) and AOT (Ahead Of Time, pre-compilation technology) Compiling modes. JIT uses JVM as an example. javac compiles the program source code into a JAVA bytecode. JVM translates the bytecode into corresponding machine commands one by one and reads them one by one, the execution speed must be slower than that of the C/C ++ compiled executable binary bytecode program. To improve the execution speed, the JIT technology is introduced, JIT analyzes the application code at runtime and identifies which methods can be classified as hot ones. These methods are compiled into the corresponding assembly code by the JIT compiler and then stored in the Code cache, you do not need to explain the execution when calling these methods in the future. You can directly use the compiled assembly code in the Code cache. This can significantly improve the application execution efficiency. (JIT is added to Android Dalvik VM 2.2.) The relative AOT is a C/C ++ language. The Compiler directly compiles the program source code into the target machine code during compilation, run the machine code directly.
The Dalvik virtual machine executes the dex bytecode, and the ART virtual machine executes the local machine code.Dalvik executes the dex bytecode and relies on the JIT compiler to explain the execution. During the runtime, it dynamically translates the frequently executed dex bytecode into the local machine code, and then runs the dex bytecode, however, the translation cost of dex bytecode occurs in the running process of the application, and each time the application re-runs, the translation must be re-performed. Therefore, JIT is adopted in a timely manner. The overall performance of the Dalvik virtual machine cannot be compared with that of the ART virtual machine that directly executes the local machine code. Replacing the Dalvik virtual machine with the ART virtual machine during Android runtime does not require developers to directly compile their applications into the target machine code. That is to say, the application is still an apk file containing the dex bytecode. Therefore, when the application is installed, the byte code in dex will be compiled to the local machine code, and each time the application is opened, the local machine code will be executed. Removed the explanation execution at runtime, which is more efficient and faster to start. (Android released the ART runtime in 4.4) Advantages of ART: ① The system performance is significantly improved ② the application starts faster, runs faster, the experience is smoother, And the touch feedback is more timely ③ the endurance is improved ④ support lower hardware ART disadvantages ① larger storage space occupation, may increase by 10%-20% ② longer application installation time. In general, ART is "Space Change Time"