Verbatim large column https://www.dazhuanlan.com/2019/08/26/5d6344d89bd96/
# #
Dalvik virtual machine is designed for the Android mobile platform this design. Small mobile platforms in general memory, disk reads very slow.
For these characteristics and limitations must be the main focus of the following objectives:
The traditional classic java virtual machine running when the class from the compressed document extract it, and then stored in memory. This implementation, not a process went back to have a separate copy, start-up speed and the process will be relatively slow because it requires a decompression process (a read or a separate class of data from the disk). Further bytecodes stored in local memory, to rewrite these commands like becomes easy, so that some optimization prompting operating.
These goals allow us to make the following decisions:
- All documents are combined into a class "DEX" document.
- DEX file is read-only, and inter-process shared use.
- And the order of the bytes for byte alignment adjusted according to the operation system.
- bytecode verification must be enforced for all classes, but the best is ahead.
- Optimizations to modify the bytecode need AOT, carried out before the process of implementation.
Divided into the following sections explain.
Application process code to the system is run by the jar or apk way. Jar and apk is actually a zip file, added some extra meta-data meta data. Dalvik DEX data file is called classes.dex.
Bytecode is not able to map directly from the zip file into memory to run directly, because the data is compressed, and byte alignment can not be guaranteed. This problem can be compressed by not dex documents, live simply put out to solve dex from zip. but this increase in the volume back to the installation package.
So we need to extract the classes.dex before the process actually executed from zip out. We can also do some of the top mentioned alignment, optimization, verification and so on. This relates to who is responsible for doing these things, treatment of where output documents in?
Preparation
There are at least create DEX document after this pre-treatment in three ways, that is what we call ODEX (Optimized DEX):
- Virtual machines "Just in time" JIT mode output document to dalvik-cache directory. This way you can in the engineering machine, but the device after the release of the real can not run because dalvik-cache directory system have access restrictions, general the app does not have permission.
- The system installer is executed after app installation. installer has write permissions as dalvik-cache.
- When the compilation system by "ahead of time" embodiment of AOT. Apk from the dex-extracting out, and performs operations such as optimization, generating odex document, but does not put / data / Dalvik-cache directory, but put / system / app directory.
dalvik-cache directory under / data / dalvik-cache directory. document permissions 0771, belongs to the system. app can only be read can not be changed.
For the "just in time" and "system installer" way to generate odex document has the following three steps:
- A first, generally created by dalvik-cache directory system installer (installd).
- Second, the classes.dex extract the document from the zip out, and part of the reserved area in the beginning of the document, the aim ODEX write head.
- Third, odex documents can mmap directly into memory for quick access, and to make some adjustments to the system currently running, including byte-swapping and structure realigning and so on. But do not do anything dex modifications to the original document. At the same time do some of the basic structure check to ensure the document such as the index offset data and not crossing the boundary.
The reason is no longer on the computer in advance to deal with these things, but there is a certain process of reason, the back will explain at run time. (This has some impact on app development because dexopt execution takes longer, but can not advance dexopt, processing only run on the target machine)
When carried out byte-swap and align, will fill odex head. Then you can start the implementation process. If you are concerned verification and optimizaiton, before executing the need to add a dexopt step. (Dexopt in fact, must be executed)
dexopt
We ask all class dex is carried verify and optimize. The easiest way is to put all the class loaded into the virtual machine and execute it again. If there is a failure then verify-optimize process fails. But unfortunately, doing so would allocate too much and it is difficult to release resources (such as load off native lib), so the verification process and we can not run the app last virtual machine process is the same.
Solve things is to call called dexopt process, running in a separate process (runtime fork a process out), is actually a virtual machine's small back door process. Dexopt until the line some small-scale vm initialized and loaded dex, then verify and optimize the implementation of the work. when complete exit process, the release of all resources.
When multiple vm need to opt for the same document, the document requires a lock to synchronize, the document is only a dexopt process to deal with him.
Verification
Bytecode verification process requires commands to scan all methods of all classes. Goal is to identify all illegal command at this stage, but do not check at runtime.
For performance reasons, to talk about the next chapter of the optimizer hypothesis verifier successfully executed. And some of the underlying assumptions will be unsafe. Dalvik will check all the class by default, and only do optimize to check off class. If you want to disable verifier may be operated by the command line in Flag. Further by http://www.netmite.com/android/mydroid/dalvik/docs/embedded-vm-control.html if the control layer in the framework.
Report verification error is a more complex matter, such as package access violations, we do not need to report an error in the blooming stage, in fact, such an inspection report at runtime can be quite time-consuming.. HTTP: //www.netmite. com / android / mydroid / dalvik / docs / verifier.html a more detailed understanding.
Be verified by the class flag will make a mark in the ODEX document. Load time will not check again.
Optimization
Virtual machine interpreter is usually done in the code first run some optimization work, such as constant pool references will be converted into an internal data structure pointer the way for the successful implementation of the code often live in some works, it will be transformed into another simpler forms, some of which work only at run time, while others can be done through a number of static rules.
Dalvik optimizer do the following:
- For virtual method call, using vtable virtual function pointer table index instead of the method index document.
- For the object field get / put operation, with 1 byte offset instead of field index. Also combined boolean / byte / char / short to a 32 bit form. (Less code in the interpreter means more room in the CPU I-cache).
- Some simple functions such as String.length () called often changed to inline functions. This reduces the consumption function calls.
- Trim empty method. The simplest example Object.
And do nothing. But each time the object allocation had to be called. Command is replaced by another new implementation, unless there is a debugger attach, or else do nothing. - Adding some good data can be calculated in advance, such as can be calculated in advance for the virtual machine to find a good class name of hashtable, without the need to perform when the re-calculation.
All of these commands modify the opcode replacement involves replacing some virtual machine specification without constraint. This is more freedom for optimized and unoptimized command combined. Optimized command and the actual significance with the virtual machine version they represent binding.
Most of the optimization work is a success. Faster using the original index and offset not only can perform, and can be ignored initialize the symbol table. It is calculated in advance to eat disk space, so the advance work needed to calculate appropriate.
Optimization work, there are some potentially troublesome. Vtable first virtual function table index and byte offset changes will occur if the virtual machine update, then the second class if a superclass of dex in another document, and update the dex , then we need to ensure our dex need to update the index and offset (that is, the need to re-opt). a similar scenario is more subtle when we customize a classloader when calling a class there may actually not us the desired class. (refers to the first in a class by dex custom classloader to load another dex in class?)
These problems are addressed with dependency lists and some limitations on what can be optimized.
Dependencies and Limitations
After optimize odex file contains a list of one to the other dex, it contains modified classes.dex original document and corresponding odex The crc. Dependency list contains the full path to the document dalvik-cache has sha-1 signature timestamp document timestamp system is not used, should not be trusted (using zip file should be in time fields). depend on the data at the same time contain the version number of vm.
optimized dex depends on all of the system bootstrap class path in dex document. bootstrap is more dependent on other bootstrap in dex of the more forward. In order to ensure that in addition to rely dex all other documents are not available, dexopt just load bootstrap in the class. the class rely on other dex can lead to load and verificatin error, there is a class dependent on external dex simply is not optimized.
This means that when the code is packaged as multiple dex when there is a negative effect: Method among their more dex call or variable reference verification process because there is no way optimized particle size of the class, there is no way to rely on outside. dex of classes optimize. While doing a bit too much, but this is the only way to guarantee a separate dex updates, does not affect other dex.
Another negative shadow: bootstrap dex for system updates, return to the dependent dex after the failure of these optimizations, need to re-opt.
Although we are very careful, but it is possible to customize a classloader using a custom, like the name of the class to return to the system of classes, such as String. In dex, if a class name and bootstrap dex of the same. Then this class is marked is ambiguous, and can not be identified optimize the process and verify the class linking code in the VM does additional checks to plug another hole;. see the verbose description in the VM sources for details (vm / oo / class.c) .
odex dexopt document output device is byte-swapped, struct-aligned relative to its operation. index offsets, etc. and includes a virtual machine and is highly consistent (including versions, platforms, etc.). For this reason, not may write a dexopt run on a pc to do this ahead of time. dexopt safest way is to perform on the device running, or the corresponding simulator.
The above language is just a translation, is feeling the need to organize a recent look at the relevant information. This can be found in the system source code.
Online links http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html