Dalvik VM start up process

Analysis of startup process of Dalvik VM

The startup of the Dalvik virtual machine starts from another famous Android module, zygote.

 

We know that in the Android system, every Java application is designed to run in a separate Linux Process. Each process contains a running Dalvik Virtual Machine instance to execute Java bytecode in the application. Many Java basic classes (such as Java. Lang. *) and some system-level shared resources (drawable/color...) will be used by almost all processes. If these resources are loaded every time a virtual machine is started, it is a great waste. In fact, the process of loading these resources in each virtual machine is exactly the same. The Android system uses a clever way to solve this problem. That is the use of zygote.

 

The focus of this series of articles is not zygote, and the implementation of zygote is also very simple. There are already a lot of introductions to it on the Internet. This article will not describe zygote in detail. Instead, it briefly describes the components connected to Dalvik.

Zygote is actually a system-level local service defined in init. RC (as shown below) and started early in system startup. Its original name is app_process (source code frameworks/base/cmds/app_process/app_main.cpp ):

// @ system/core/rootdir/int.rc

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server    class main    socket zygote stream 666    onrestart write /sys/android_power/request_state wake    onrestart write /sys/power/state on    onrestart restart media    onrestart restart netd

After the service is started, it loads the basic classes and resources mentioned above and creates a socket (the name is zygote as shown above ). After other Java applications are started, AMS (Java service used in Android to manage activity) Requests zygote Fock () A sub-process through this pipeline. The sub-process inherits the memory zone of Zygote, which is directly used for classes and resources loaded by zygote. In this way, the Linux Process running Java applications avoids repeated loading of Android basic classes and general resources, thus greatly saving time.

The Dalvik VM references [3] A description of the process:

We can see that all applications (maps, browser, Home) inherit the shared library from the parent process of zygote ..

 

From the above description, we can guess that the startup of Dalvik must be associated with the implementation of zygote. Indeed, the startup of the Dalvik Virtual Machine instance is caused by zygote. This article will detail this process. However, this article does not directly use the sequence tracing method mentioned above to show the process of starting a Dalvik Virtual Machine instance from zygote. Instead, we first adopt reverse tracing. The purpose is as follows: 1. Introduce the use of reverse tracing 2. Deepen Your impression on the entire process.

From the implementation of the Dalvik Virtual Machine (Dalvik/Vm), we can see that there are two files init. h and init. cpp. We can guess from the name that this file may be related to virtual machine initialization. Initialization must be completed at startup. Open init. h and we can see the following functions:

From the naming point of view, this is probably the function that the Dalvik virtual machine starts and closes. In init. cpp, we can see their implementation. Although we still cannot fully understand the implementation details, we can be sure of our judgment on the two functions just now.

Okay. We found the startup function dvmstartup () initialized by the VM (). As a result, we have a prerequisite for using reverse tracing (a later execution point ). Based on this point, we can trace how the virtual machine is started. The following is a simple process description:

1. Use the full-text search function dvmstartup () in the code. Fortunately, there is only one real call:

Dalvik/Vm/JNI. cpp

3494Dvmstartup(Argc, argv. Get (), argS-> ignoreunrecognized, (jnienv *) penv );

Then the start function must be called from JNI. cpp, which is consistent with the comment of the modified function ("usually invoked through JNI ")

 

2. In JNI. CPP, the call to dvmstartup () is performed in the functionJni_createjavavm. Continue to search for the function call. Filter out the Declaration and definition of the function. We can see the following calls:

Frameworks/base/services/surfaceflinger/ddmconnection. cpp

43 If (Jni_createjavavm(& Vm, & ENV, & ARGs) = 0 ){

 

Dalvik/dalvikvm/Main. cpp

212 If (Jni_createjavavm(& Vm, & ENV, & initargs) <0) {

 

Frameworks/base/CORE/JNI/androidruntime. cpp

768 if (Jni_createjavavm(Pjavavm, penv, & initargs) <0 ){ 769 LogE ("Jni_createjavavmFailed \ n ");

We know that surfaceflinger is a local service used in Android for the underlying compositing layer, which is unlikely to serve as the starting point for starting all Virtual Machine instances. The other two are very likely.

In the previous article XXX (Todo), we mentioned that Dalvik implementation deployment contains two parts: dalvikvm executable program and libdvm shared library. These two calls correspond to the entry of two methods to start the Dalvik virtual machine. The executable program dalvikvm runs jni_createjavavm in Main. cpp to start the VM instance, while other modules start the VM instance through androidruntime. cpp.

The dalvikvm executable program is introduced in a separate chapter. Here we trace how the logic is executed to start the VM instance in androidruntime. cpp under normal circumstances.

 

3. Enter androidruntime. cpp. We can see that it is inAndroidruntime::Startvm. To continue searching for the function call, there is only one and is in the same file:

Frameworks/base/CORE/JNI/androidruntime. cpp

464 int androidruntime ::Startvm(JavaVM ** pjavavm, jnienv ** penv)Function In Class: Android: androidruntime  832 if (Startvm(& Mjavavm, & env )! = 0 ){

 

The function called is as follows:

From the comments of this function, we can see that the tracking direction is correct.

 

4. Continue and get a huge number of search results when you start the full-text search. After all, this function name is too common. Searching for androidruntime: Start is defined only. It is no wonder that this method is not a class method and will not be called using androidruntime: Start (XXX.

You can only search for classes that appear at the same time as androidruntime and start (), and only search for classes that must have start. In this way, the search result is reduced to less than, and it is easy to determine whether the start function is called. In the result, we can see it at a Glance:

Frameworks/base/cmds/app_process/app_main.cpp

15 # include <android_runtime/Androidruntime. H> 25 "Usage: app_process [Java-options] cmd-DirStart-Class-name [Options] \ n "); 28 class appruntime: PublicAndroidruntime 68 * the easiest fix is to call findclass here, early on before weStart 88Androidruntime* AR =Androidruntime: Getruntime (); 108Androidruntime: Onexit (CODE ); 169} else if (strcmp (ARG ,"--Start-System-server ") = 0 ){ 189 runtime.Start("Com. Android. Internal. OS. zygoteinit ", 190 startsystemserver? "Start

Is the file name very familiar? Yes, as we mentioned earlier, the source code starting point of zygote implementation is this file.

 

5. Expand and modify the file's call to start. It is found that the appruntime instance is calling and modifying the function, not androidruntime! Find the appruntime implementation and find that it is a subclass of androidruntime, and it does not overwrite the START () method, so it must call the START () method of androidruntime. So far, we have traced back to how zygote started the Dalvik Virtual Machine instance.

Out of curiosity, let's look at what the start class "com. Android. Internal. OS. zygoteinit" is doing. Its source code is in frameworks/base/CORE/Java/COM/Android/Internal/OS/zygoteinit. java. We can see a lot of implementation of interaction between zygote and DVM from its perspective. For example, register a socket and load basic classes and resources.

 

So far, we can outline the entire process of starting a DVM instance in sequence: