Processing of Dalvik class loading

The Java source code is compiled to generate a file with a suffix of class, also known as a bytecode file. Then use the DX tool in Android to convert it to a Dex type file with a jar suffix. The Dalvik virtual machine is responsible for interpreting and executing the compiled byte code. Before interpreting the execution bytecode, it is of course necessary to read the file, analyze the contents of the file, and get the bytecode before interpreting the execution. In the entire load process, the most important thing is to Class loading –class contains method, and method contains code. By loading the Class, we can get the byte code that we need to execute.

This paper starts with the data structure of dexfile file analysis and Class loading, and analyzes the whole loading process with the main flow, which is expected to be helpful to everyone.

1. Dexfile in-memory mapping

In the Android system, the Java source file is compiled as a Dex type file with a suffix of jar, called Dexfile in the code. Before you load Class, you must read the appropriate jar file. Usually we use the Read function to read the contents of the file. However, using the Mmap function in Dalvik, unlike read, the MMAP function maps the Dex file to memory, so that the contents of Dex files can be accessed through normal memory read operations.

The Dexfile file format, shown in the following figure, consists of three main parts: Head, Index, data. The location and number of the index can be seen from the head, which indicates the starting position of the data area. Where Classdefsoff specifies the starting position of the classdef at the beginning of the file, Dataoff specifies the data at the start of the file, ClassDef can be interpreted as the index of Class. You can learn the basic information of class by reading ClassDef, where Classdataoff specifies the location of the class data in the data area.

After mapping the Dexfile file to memory, the Dexfileparse function is called to analyze the results of the analysis, which are stored in the data structure named Dexfile. The baseaddr in Dexfile points to the starting position of the mapping area, pclassdefs the starting position of the classdefs (that is, the class index). Because the name of the class is used to find the class, a hash table is created to speed up the lookup. Hash the class name in the hash table and generate index. These operations are done when parsing a file so that while it is time-consuming to load, it can save a lot of lookup time during the run.

2. Classobject-class in the form of loading

After the completion of the file parsing will load the specific content of Class. In Dalvik, the data structure of Classobject is responsible for storing the loaded information. As shown in the following illustration, the loading process alloc several areas in memory, storing Directmethods, Virtualmethods, Sfields, and Ifields respectively. This information is read from the data area of the Dex file. The Class details are read first, and the information from Directmethod, Virtualmethod, Sfield, Ifield, and so on is read. The figure below is a schematic of the completion of the load. This does not describe the loading of each detail, interested students can be analyzed by the two diagrams themselves.

Please also note that there is a member named Super in the Classobject structure. The super class is pointed to by the super member.

3. findclassnoinit– is responsible for loading the Class and generating the corresponding classobject function.

The second section describes the data structures that are loaded, and this section analyzes the functions that are responsible for loading the work-findclassnoinit. Note that when you get the class index, you are divided into Basic class library files and user class files in two cases. In the preparation of Dalvik analysis, GRUND.SH has a statement "Export bootclasspath= $bootpath/core.jar: $bootpath/ext.jar: $bootpath/framework.jar: $bootpath/android.police.jar ". This statement specifies the base library file required for Dalvik, and if there is no such statement, the Dalvik will error out during startup.

The Loadclassfromdex function first reads the specific data of Class (from Classdataoff) and then netizens, loading Directmethod, Virtualmethod, Ifield, Sfield, respectively.

As the industry top company produced Dongdong, of course, pay attention to the implementation efficiency ^_^. First of all, we need to cache it after loading so that it is convenient to use later. Second, in the search process, if we look in order, of course, is very slow pull. This is of course our senior engineer can not tolerate, so gdvm.loadedclasses this Hash table on the grand appearance. What, this classmate said not a few class, as for such a big fuss. Let's see, by using the method described in the preparation article, we set breakpoints in the MAIN.C 249 line, at which point the base library is loaded. When the program stops, we look at the value of the GDVM and we see that the value of the numloadedclasses member is 212. That means we didn't do anything at this time, the user class is not loaded, the number of classes loaded by Dalvik has reached 212.

Dvmlinkclass, it's so long, but eventually it seems like it will call Findclassnoinit again. Well, it is understandable. If a subclass needs to call a superclass function, then of course it loads the superclass and, if possible, even the superclass ^_^.

Seeing for the virtual, practice the truth, take GDB debugging.

Set breakpoints at the Findclassnoinit function (enter "b findclassnoinit" at the GDB prompt) and perform "C" and "BT" several consecutive times after the GDB prompt. You can see findclassnoinit on the function call stack when you can see the following information.

(GDB) bt

#0 Findclassnoinit (descriptor=0xfef4c7f4 "?????? % ", loader=0x0, pdvmdex=0x0)

At dalvik/vm/oo/class.c:1373

#1 0xf6fc4d53 in Dvmfindclassnoinit (descriptor=0xf5046a63 "ljava/lang/object;", loader=0x0)

At dalvik/vm/oo/class.c:1194

#2 0xf6fc6c0a in Dvmresolveclass (referrer=0xf5837400, classidx=290,

Fromunverifiedconstant=false) at dalvik/vm/oo/resolve.c:94

#3 0xf6fc3476 in Dvmlinkclass (clazz=0xf5837400, Classesresolved=false)

At dalvik/vm/oo/class.c:2537

#4 0xf6fc1b67 in Findclassnoinit (Descriptor=0xf6ff0df6 "Ljava/lang/class;", loader=0x0,

pdvmdex=0xa04c720) at dalvik/vm/oo/class.c:1489

Now look at it from another angle. Set a breakpoint on the CLASS.C 2575 line and wait for the program to stop. Look at the contents of the Clazz.

(GDB) P Clazz->super->descriptor

$ = 0xf5046a63 "Ljava/lang/object;"

(GDB) P Clazz->descriptor

$ = 0xf5046121 "Ljava/lang/class;"

4. Basic class library file loading

First set the breakpoint at the Findclassnoinit function, and then run the program, waiting for the program to stop.

(GDB) B findclassnoinit

Breakpoint 2 at 0xf6fc13e0:file dalvik/vm/oo/class.c, line 1373.

(GDB) C

Continuing.

See who is the first loaded Class, and its calling relationship.

(GDB) bt

#0 Findclassnoinit (descriptor=0x0, loader=0x0, pdvmdex=0x0) at dalvik/vm/oo/class.c:1373

#1 0xf6fc32a1 in Dvmlinkclass (clazz=0xf5837350, Classesresolved=false)

At dalvik/vm/oo/class.c:2491

#2 0xf6fc1b67 in Findclassnoinit (descriptor=0xf6ff1ded "ljava/lang/thread;", loader=0x0,

pdvmdex=0xa04c720) at dalvik/vm/oo/class.c:1489

#3 0xf6f92692 in Dvmthreadobjstartup () at dalvik/vm/thread.c:328

#4 0xf6f800e6 in Dvmstartup (argc=2, argv=0xa041190, Ignoreunrecognized=false, penv=0xa0411a0)

At dalvik/vm/init.c:1155

#5 0xf6f8b8e3 in JNI_CREATEJAVAVM (P_vm=0xf6ff0df6, P_env=0xf6ff0df6, vm_args=0xfef4d0b0)

At dalvik/vm/jni.c:4198

#6 0x08048893 in Main (argc=3, argv=0xfef4d168) at dalvik/dalvikvm/main.c:212

Function call order is clearly visible: main-> jni_createjavavm-> dvmstartup-> dvmthreadobjstartup-> dvmfindsystemclassnoinit- > Findclassnoinit Observation carefully students may ask in the call stack did not see Dvmfindsystemclassnoinit ah, why do you write Ah. I estimate that the compiler will use it as a inline