Dalvik: Dex

dex header 中主要下面提到的各个 ids, defs 的 size 和 offset, 以便能找到这些 table, 例如:

struct header_item {
    struct dex_magic {
        /* dex.. */
    };
    uint checksum;
    char signature[20];
    uint file_size;
    uint header_size;
    uint endian_tag;
    uint link_size;
    uint link_off;
    uint map_off;               /* map list offset */
    uint string_ids_size;
    uint string_ids_off;
    uint type_ids_size;
    uint type_ids_off;
    uint proto_ids_size;
    uint proto_ids_off;
    uint field_ids_size;
    uint field_ids_off;
    uint method_ids_size;
    uint mehtod_ids_off;
    uint class_defs_size;
    uint class_defs_off;
    uint data_size;
    uint data_off;              /* data_off 可能主要用来检查 */
};

struct string_id_list {
    struct string_id_item {
        uint string_data_off;
    } [string_ids_size];
};

通过这个 string_data_off, 可以在 data 部分找到这个 string 对应的 string_item 结构.

class defs 是这些表中是复杂的一个表.

struct class_def_item_list {
    struct class_def_item {
        uint class_idx;             /* => type_id_item */
        enum ACCESS_FLAGS;
        uint superclass_idx;        /* => type_id_item */
        uint interface_off;
        uint source_file_idx;       /* => string_id_item */
        uint annotation_off;
        uint class_data_off;
        uint static_value_off;
    } [class_defs_size];
};

与 string_id_item 中的 string_data_off 及 proto_id_item 中的 parameters_off 类似, class_def_item 中包含四项 off 也存在到 data 部分,

struct map_list_type {
    uint size;
    struct map_item_list {
        struct map_item {
            enum type;
            ushort unused;
            uint size;
            uint offset;
        } [size];
    };
};

`This is a list of the entire contents of a file, in order. It contains some redundancy with respect to the header_item but is intended to be an easy form to use to iterate over an entire file.`

map_list 中保存着许多不同类型的 entry 对应的 offset, 与 header_item 有些重复, 例如以下类型的 entry 在 header_item 中也是存在的

• TYPE_TYPE_ID_ITEM
• TYPE_PROTO_ID_ITEM
• TYPE_FIELD_ID_ITEM
• …

但它也可以包含以下类型:

• TYPE_CLASS_DATA_ITEM
• TYPE_CODE_ITEM
• TYPE_STRING_DATA_ITEM
• …

这些数据在 header_item 是不存在的, 以 CLASS_DATA_ITEM 为例, 如果不使用中 map_list, 必须通过 header_item -> class_def_item -> class_data_item 这条路径才能找到. 有了 map_list, 代码可以用一种更简单一致的方法来遍历整个 dex 文件.

register map 主要用来帮助 dvm 知道在每个函数的每个 GC Point 处当前各个寄存器中哪些保存着 java 对象.以便进行 exact GC. register map 导致 odex 比 dex 大了 9% 左右.

在 Hotspot 中, 也有一个类似的结构称为 OopMap

若没有这个 map, 则 GC 只能进行 conservative GC, 即 GC 时 dvm 只能假设当前所有寄存器中都保存着对象引用, 从而导致一些本来已经是 garbage 的对象没有被回收. (例如 r1 本来保存着一个整数 0xxxxx, 但这个整数刚好对应着某个已经不可达的对象的地址, 那么这个对象就会被重新标记为可达).

conservative GC 可能通过堆内存上下界检查, 对齐检查 (java 对象都是 8 字节对齐) 等方法过滤掉一些明显不可能是引用的值. 但它相对于 exact GC 还是有两方面明显的问题:

1. 某些对象不会被回收, 导致内存压力
2. 无法支持 copying GC.

• verification
• optimization /dalvik/vm/analysis/Optimize.cpp::optimizeMethod

  1. quick 替换 与 符号解析

     将本来 java 在类加载时完成的符号解析的工作拿出来,提前将符号解析出来, 并且使用相应的 `quick' 指令代替原来的基于常量池符号引用的指令, 例如: 将之前的

     invoke-virtual {v0,v1},Ljava/io/PrintStream;->println(Ljava/lang/String;)V
     

     替换为

     invoke-virtual-quick {v0,v1},vtable #0x3b
     

  2. inline method
  3. …
• register map

1. From the VM. This takes a dozen args, one of which is a file descriptor that acts as both input and output. This allows us to remain ignorant of where the DEX data originally came from.
2. From installd or another native application. Pass in a file descriptor for a zip file, a file descriptor for the output, and a filename for debug messages. Many assumptions are made about what's going on (verification + optimization are enabled, boot class path is in BOOTCLASSPATH, etc).
3. On the host during a build for preoptimization. This behaves almost the same as (2), except it takes file names instead of file descriptors.

1. zygote 启动时 zygote 启动时会负责 boot class 的 dexopt (通过 dvmClassStartup -> prepareCpe -> dvmRawDexFileOpen)
2. PMS.performBootDexOpt PMS 启动时
3. AMS.ensurePackageDexOpt AMS 启动应用之前
4. dvmRawDexFileOpen ClassLoader 初始化时
5. app 被安装时

ClassLoader 并不是一定要在 native 实现的, 有些 ClassLoader 是完全用 Java 写的. 但 dalvik 的 ClassLoader 因为底层都依赖于 dex, 所以都是通过 native 层的 DexFile (代表 dex), RawDexFile (代表 odex), DvmDex (代表 auxiliary cache) 实现的.

Java 层和 ClassLoader 相关的类主要有:

1. VMClassLoader
2. ClassLoader
3. BootClassLoader
4. BaseDexClassLoader
5. PathClassLoader

                 -+-------------+
                  | ClassLoader |
                 -+-----+-------+
                        |
                        |
          -+------------+-----------------+
           |                              |
           |                              |
    -+-----+-----------+          -+------+-------------+
     | BootClassLoader |           | BaseDexClassLoader |
    -+-----+-----------+          -+------+-------------+
           |                              |
 comp      |                       comp   |
-+---------+-----+                -+------+---+
 | VMClassLoader |                 | DexFile  |
-+---------+-----+                -+------+---+
           |                              |
           |                              |
       native                         native

ClassLoader 这个基类主要作用是实现双亲委派

protected Class<?> loadClass(String className) {
    Class<?> clazz = findLoadedClass(className);

    if (clazz == null) {
        try {
            clazz = parent.loadClass(className, false);
        } catch (ClassNotFoundException e) {
            // Don't want to see this.
        }

        if (clazz == null) {
            clazz = findClass(className);
        }
    }
    return clazz;
}

ClassLoader 通过 parent 指针可以形成一棵树, BootClassLoader 是树根.

在 dalvik 底层代码中并没有 BootClassLoader 这个东西: dalvik 通过把 clazz->classLoader 置为 NULL 表示该 class 是由 BootClassLoader 加载的.

/* defining class loader, or NULL for the "bootstrap" system loader */
Object*         classLoader;

简单起见, 我们假设 BaseDexClassLoader 的 parent 都是 BootClassLoader, 所以 PathClassLoader 的 loadClass 会先调用 BootClassLoader 的 loadClass:

BootClassLoader.loadClass
  BootClassLoader.findClass
    VMClassLoader.loadClass(name, false);
      // native, 其中 null 表示 ClassLoader 为 null, 以
      // 便从 bootstrap class 中查找
      clazz = dvmFindClassByName(nameObj, NULL, resolve);
        dvmFindClassNoInit
          dvmFindSystemClassNoInit
            findClassNoInit(descriptor, null);

若 BootClassLoader 没有找到 class, 则使用 BaseDexClassLoader 有加载

BaseDexClassLoader.findClass(String name)
  Class c = pathList.findClass(name, suppressedExceptions);
    Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
      DexFile.defineClassNative(name, loader, cookie);
        // native
        clazz = dvmDefineClass(pDvmDex, descriptor, loader);
          findClassNoInit(descriptor, loader);

无论是 VMClassLoader 或是 DexFile, 最终都通过 native 的 findClassNoInit 进行 dex 的加载

和类加载相关的入口主要有:

1. dvmFindClassNoInit
   1. findClassNoInit
2. dvmResolveClass
3. java 层的 classForName
4. java 层的 ClassLoader.loadClass

1. 对于 dvmResolveClass 和 classForName 都需要提交根据 curMethod->clazz->classLoader 获得`定义当前 method 的 class 使用的 classLoader`, 并使用这个 classLoader 调用 dvmFindClassNoInit, 这是 jvm 规范要求的.

2. dvmFindClassNoInit 加载类时, 要 classLoader 不为空, 则使用 classLoader 来加载, 否则使用 dvmFindSystemClassNoInit 从 bootstrap classpath 中加载 (即从 `BootClassLoader` 中加载)

   通过 ClassLoader 加载时, java 层的双亲委派会优先使用 BootClassLoader 来加载, BootClassLoader 最终会通过 dvmFindSystemClassNoInit 来加载.

   若 BootClassLoader 没有加载成功, 则 BaseDexClassLoader 的 findClass 会负责通过 dvmDefineClass(pDvmDex, descriptor, loader) 在 app 自己的 dex 中加载类.

   即 dvmFindClassNoInit 与 java 层的各种 ClassLoader 类实现了 dalvik 的双亲委派模型.

3. 最终 dex 都是通过 findClassNoInit 加载进来的. findClassNoInit 是负责从 ClassLoader 对应的 dexFile (若 ClassLoader 为空则从 boot class path) 中加载类, 它无须再考虑双亲委派.

4. dvmFindClassNoInit 或 findClassNoInit 过程中, 都会用到 dvmLookupClass 来避免重复的加载.

   dvmLookupClass 进行查找时考虑到 clazz->loader 因为双亲委派的原因可能不是真正发起类加载的那个 ClassLoader, 所以它使用了 clazz->initiatingLoaderList 来记录这些信息.

pre-verify 实际上指的就是 dexopt 时进行的 verify. 在默认配制下, dexopt 会先对 dex 进行 verify, 然后再进行 optimization. 实际上, 默认配制下 dexopt 要求必须先 verify 以后才能进行 optimization. 所以 pre-verify 发生的时机就是 dexopt 发生的时机: 例如通过 zygote 的 dvmClassStartup.

通过 dexopt 的 pre-verify, odex 中的 class 对象的 CLASS_ISPREVERIFIED 标志会被置位, 这个标记会阻止后续 dvminitclass 时的 dvmVerifyClass 调用.

实际上, pre-verify, dexopt 合起来做为 dex 的 prepare

通过 setprop dalvik.vm.verify-bytecode false, 可以禁用整个 dex prepare 过程 (包括 pre-verify 和 dexopt). 若开机启动时因为这个 prop 没有进行 verify, 但运行时通过 setprop dalvik.vm.verify-bytecode true 或直接通过 dalvik 的启动参数 (-Xverify:all 或 -Xverify:remote) 重新启用了 verify, 则在 class 初始化时, 会调用 dvmVerifyClass 进行 verify. 这种运行时的 verify 会导致应用加载明显变慢 (可能 40% 以上)

Xverify 参数接受三种值:

1. all 所有 class 被需要被 verify
2. remote boot class 以外的 class 需要被 verify
3. none 任何 class 都不会被 verify

这里有一个 java 文件:

class Test2 {
    private static int a = 10;
}

public class Test {
    public static void main(String[] args) {
        System.out.println("hello: "+Test2.a);
    }
}

但这个 java 文件是编译不过, 为了让 javac 能生成这个语义的 class 文件(让 class 中的 main 函数直接访问 Test2 的私有成员), 我们可以这样操作:

1. 把 private 暂时改为 public, javac Test.java
2. 把生成的 Test.class 保存起来
3. 把 public 变回 private, 但把 System.out.println 一行去掉, 然后 javac Test.java, 把 Test2.class 保存起来
4. 把两次保存的 Test.class 和 Test2.class 打包为 Test.dex. 这样 Test.dex 中就会包含 Test 访问 Test2 的私有变量这样的非法代码.

在手机上用 dalvikvm 命令执行, 分别指定不同的 Xverify 和 Sexpot 参数:

1. dalvikvm -Xverify:none -Xdexopt:all -cp Test.dex Test
   • dalvik-cache 下有 odex 生成, 且 Test 确实被优化了 (invoke-virtual 被替换为 invoke-virtual-quick)
   • 程序正常输出 10
2. dalvikvm -Xverify:all -Xdexopt:all -cp Test.dex Test
   • dalvik-cache 下有 odex 生成, 且 Test 被优化

   • 程序报错:

     root@scx15_sp7715ga:/data # dalvikvm -Xverify:all -Xdexopt:all -cp Test.dex Te>
     Unable to find static main(String[]) in 'Test'
     java.lang.VerifyError: Test
             at dalvik.system.NativeStart.main(Native Method)
     java.lang.VerifyError: Test
             at dalvik.system.NativeStart.main(Native Method)
     

     这里报错是因为: Xverify:all 会导致 dexopt 时进行 pre-verify, 但这里 verify 会失败, 所以 class 不会被标记为 PREVERIFIED, 但因为 Xdexopt:all, 所以虽然 pre-verify 失败了, dexopt 还是会进行优化, 最终 odex 中包括的 Test 类是优化后的结果.

     dvminitclass @ Class.cpp 中的这段代码:

     if (clazz->status < CLASS_VERIFIED) {
         // ...
         if (IS_CLASS_FLAG_SET(clazz, CLASS_ISOPTIMIZED)) {
             ALOGW("Class '%s' was optimized without verification; "
                   "not verifying now",
                   clazz->descriptor);
             ALOGW("  ('rm /data/dalvik-cache/*' and restart to fix this)");
             // verify_failed 处会抛出异常
             goto verify_failed;
         }
     }
     

     会抛出上面的异常.

     即: 若 class 没有通过 verify 就被 dexopt, 则在 dvmInitClass 的阶段, dalvik 就会主动抛出异常. 这样做的原因可能是: 因为 code 已经被 dexopt, 这里可能无法再 replaceFailingInstruction

3. dalvikvm -Xverify:all -Xdexopt:none -cp Test.dex Test
   • dalvik-cache 下有 odex 生成, 但 Test 没有被优化

   • 程序报错:

     root@scx15_sp7715ga:/data # dalvikvm -Xverify:all -Xdexopt:none -cp Test.dex T>
     java.lang.IllegalAccessError: tried to access field Test2.a from class Test
             at Test.main(Test.java:6)
             at dalvik.system.NativeStart.main(Native Method)
     

     这里报错是因为: Xverify:all 会导致 pre-verify, 但 pre-verify 会失败, 导致后续 dvmInitClass 还会再次调用 dvmVerifyClass 进行 late verify. (因为 Xdexopt 为 none, 所以不会发生 case 2 的问题). late verify 时还是会失败, 这里会通过 replaceFailingInstruction 将原来的指令 (sget) 替换为一个抛出异常的指令, 但这里做的仅仅是指令替换, 并不会直接抛出异常. 当被替换的指令直接执行时, 才会报错.

综上:

1. 无法 Xdexopt 如何指定, odex 总是会生成, 但 Xdexopt 会影响 odex 中的代码是优化过的还是 dex 中的原始代码.
2. Xverify 会影响 dexopt 时的 pre-verify 和 class 加载时的 late verify
3. 在 late verify 阶段, 若当前代码并没有被 dexopt 优化, 则会通过 replaceFailingInstruction 进行指令替换, 否则直接报错
4. 默认情况下 Xverify = all, Xdexopt = verified, 所以, 若一个类有问题, 则会在运行时报错 (通过 replaceFailingInstruction), 而不是在 verify 阶段 (pre-verify 或 late verify) 报错. 抛开 pre-verify, dexopt 这些不谈, java 的 verify 的功能本质上就是 replaceFailingInstruction