Android Dalvik Virtual Machine

Improved JVM Virtual Machine

Dalvik is based on registers, while
JVM is stack-based. Register-based virtual machines take less time to compile larger programs.

Differences between Dalvik and Java runtime Environments

　　^{[2] 1: Dalvik is mainly used to complete important functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.}

2: Dalvik is responsible for process isolation and thread management. Each Android Application corresponds to an independent Dalvik Virtual Machine instance at the underlying layer, and its code can be executed under the interpretation of the virtual machine.

3: Unlike Java bytecode running on java virtual machines, Dalvik virtual machines run their proprietary file format Dex

4: The Dex file format reduces the size of the entire file and improves the Class search speed for I/O operations.

5: odex is used to further improve the performance of the DEX file during running.

6: All Android Application threads correspond to a Linux thread. Therefore, virtual machines can rely more on the thread scheduling and management mechanism of the operating system.

7: there is a special Virtual Machine Process zygote, which is the incubator of Virtual Machine instances. It is generated when the system is started. It completes VM initialization, Library Loading, pre-made class libraries, and initialization operations. If the system needs a new Virtual Machine instance, it will quickly replicate itself and provide the fastest data to the system. For some read-only system libraries, All VM instances share a memory area with zygote.

In fact, the core difference is that the Dalvik virtual machine architecture is register-based, which is different from the stack-based architecture of Sun JDK. I have extracted a few pieces of information that can be found on the Internet and reorganized and typeset it. The original author is unknown because these materials have been reproduced, forwarded, and processed on the Internet for many times, therefore, you cannot mark the original authors. If the original authors claim or question them, please notify me in time.

(1) The first difference between Dalvik Vm and JVM is that Dalvik VM is a register-based architecture (REG based), while JVM is a stack based machine (stack based ). The advantage of Reg based VM is that it can achieve better advance optimization (ahead-of-time optimization ).
In addition, reg-based VMS run faster, but the cost is higher code length.
(2) Another difference is that Dalvik can allow multiple instances to run, that is, each Android app runs independently in a VM. the advantage of this is that an app crash only affects its Vm and does not affect others. The Design of Dalvik is that every Dalvik VM is a process under Linux. This requires efficient IPC. In addition, each VM runs independently. It can dynamically active/deactive its own VMS without affecting other VMS.
(3) The following is a debate about copyright. (See the following article)
Since reg-based VM has so many advantages, why did the people who designed Java use stack-based instead of reg-based? The original stack-based VM also has its advantages, that is, it does not make assumptions about the number of Reg on the host platform, which is conducive to porting to different platforms. Dalvik does not care about this because it was originally designed for multi-Reg platforms like arm. In addition, if Dalvik is transplanted to x86, even for a platform with few Reg such as x86, Reg
There is no problem with the based VM.

The following describes the advantages of DVM: (I add some texts to highlight them)
1. Optimize the code in advance during compilation instead of waiting for execution
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 VMS, evaluate the source architecture
The stack or register may all 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 completed 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 piece of Java code below: some articles on the Internet are discussing
When using Dalvik, it is generally mentioned that the execution speed of Dalvik is faster than that of JVM, but the portability is slightly lower. Here we will discuss it further. Execute VM commands on an interpreter in three steps: Command assignment, access operations, and execution calculation. Instructions dispatch is responsible for reading VM commands from the memory, and then redirecting to the corresponding interpreter code command dispatching. As mentioned above, to do the same thing, stack-based virtual machines require more commands, meaning more command assignment and memory access times, this is one of the reasons that the JVM's execution performance is inferior to that of the Dalvik VM.
Operands access refers to the read and write back-to-source operations and destination operations. Dalvik VM accesses the operand through the Virtual operand register. Because of its close kinship, Dalvik's virtual register has more advantages in ing to the physical register. This is also Dalvik's
One reason why the VM performance is better. The JVM's operands are accessed through the operand stack. Because no General registers are used in the instruction, the virtual machine implementation can freely allocate the actual machine's storage device, which is highly portable. As an optimization, the operand stack can also be mapped to physical registers by the compiler to reduce the overhead of data movement. The command execution (Instructions compute) does not seem to have much to explain. It can be implemented honestly. Command Execution

Many classes are defined in an application. After compilation, many corresponding class files are generated, and many redundant information is generated between class files.
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.
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.
==================================================================== ========================
Next, I will give a brief summary of the impact of the differences between DVM and JVM architectures.


The core objective of JVM is to build a cross-OS platform and cross-Instruction Set Runtime Environment (VM ). DVM aims to provide Android OS local resources and environments with a unified interface for application development. Strictly speaking, DVM is not a real VM. It only provides the VM environment during development and does not provide real VM containers during running. This is also the reason why the JVM must be designed as a stack-based.

JVM: The runtime environment of all jar programs is completely provided by JVM, including scheduling of various resources during runtime, while the JVM architecture, it is designed to run multiple Java programs in a JVM. The JVM is like a real "machine" and can run multiple programs. If you look at some enterprise-level JVMs (such as Tom Cat and was), you can only see one JVM process in OS process management (of course, you can also start multiple JVMs, but the JVM architecture is the three-layer runtime mode of the OS-JVM-APP), and can not see the program running in the JVM, and a JVM, can run multiple Java
App. To put it simply, the JVM completely shields the connection between applications and OS, and uses the JVM as the middle layer. This is what the VM must do during cross-platform running. As long as the JDK is the same, JVM provides a completely consistent runtime environment for all programs running in it, regardless of what underlying OS and hardware conditions you have. Therefore, I mentioned in another article that JVM is characterized by the intersection of the underlying OS and hardware environment to ensure this consistency. The interaction between all applications and underlying resources must be achieved through JVM transmission and conversion. JVM implements all the functions that an OS can manage when running an application. From the perspective of development environment and runtime, they are all consistent real VMS.

DVM: DVM features zygote, which has several interesting features.
First, zygote uses the pre-load method to determine the needs of the installed APK and the dependency tree, as well as the features of the OS and hardware environment, perform pre-loading at every startup (now you understand why Android apps can easily find out why they all call key local resources in application management ?), This means that the more applications you install, the slower the zygote loading. Generally, the slower the startup of your mobile phone. In addition, instances initialized by zygote in different hardware environments (for example, with or without a GPS chip) are different. That is to say, zygote does not provide a unified operating environment and is more flexible. This mechanism means that DVM can use the collection of underlying resources to provide upper-layer applications, the difference is that when the program is installed or started, DVM can prompt the program to request resources, and the local environment may fail to meet the requirements, resulting in failure to run. DVM's zygote does not provide a runtime container. It only provides a shared process. All applications run independently and are OS-level processes, directly influenced by OS-level resource control and scheduling, they only share zygote's pre-loaded class. That's why I said that DVM is like adding a set of sub-scripts to each application at the underlying layer, rather than providing a real runtime VM. That is to say, the VM platform provided by DVM in the development environment may be inconsistent with the runtime environment. The VM platform provided in the development environment is a collection of various runtime environments.
From this point, we generally think that the failure of Java programs in JVM can lead to the failure of JVM at most, but does not lead to OS crash, but the crash of APK can directly lead to OS crash, android phones will crash because of applications, which should be common. But we generally don't see the Java program causing a crash, right? Because there is a JVM In The Middle Of The runtime. (Of course, there are still some small doorways that can use Java programs to crash the OS. Because of this, I bet with some java danale that I won the dinner, but this is another topic, not here)

In addition, in the JVM mechanism, different programs, After packaging, all of them are truly independent programs at the running level (that is, the relationship between program applications and each other, ), even if they use the same class in the package, the runtime is loaded separately and run independently (and loaded multiple times ).
The pre-load-sharing mechanism of DVM enables different applications to share the same class at runtime. In general, DVM has a higher efficiency in terms of system resource consumption.

Finally, we can add that byte code does not mean interpretation and execution, but also load compilation, install compilation, pre-compilation, and so on. In fact, the actual execution of different byte code programs, different technologies, and different specific languages is complicated and difficult to generalize. Many of them are mixed technology cases, my odex technology is a typical case. Of course this is a digress.