前言

这里以 hprof 功能来进行对比，老架构最大的问题是进行转 hprof 文件严重耗时，而新架构引入了新的概念将此性能提升了原来的 10 倍，让原本较大的 Java 堆内存的 coredump -> hprof 花费 1 ~ 2 小时缩减到 6 ~ 12 分钟。

对象计算路径

例如地址为 0x12c00000 的 Java 对象，解析它所有的成员的计算路径，总体计算上需要寻找以下内存。

我们得到地址如 0x12c00000 是不能直接使用的，需要进行转换成对应 Core 文件的偏移地址后才能使用，而计算文件偏移不能简单的加减，在解析器上地址转换过程相对耗时，单次解析对象平均时间如果超过 0.00144 秒，那么在解析 500'0000 个对象的数据量则需要 2 个小时才能完成。

旧架构

采用传统地址转换计算模型，遍历所有的 Load 段，找到对应段在进行计算。

新架构

新的模型则是在加载 Core 文件初始化时，为 Load 段创建了相应的 LoadBlock 的对象，并且删掉部分不可用的段。最主要的是所有指针/对象都继承内存引用 MemoryRef。

虚实绑定

LoadBlock 直接绑定了 1 个虚地址与 3 个实地址，程序只需找到对应的 LoadBlock 即可直接找到 3 个不同的实地址来计算，但不是影响性能的根本，而是基础。

arduino 复制代码

class Block {
public:
    ...
private:
    //  program member
    uint32_t mFlags;
    uint64_t mOffset;
    uint64_t mVaddr;
    uint64_t mPaddr;
    uint64_t mFileSize;
    uint64_t mMemSize;
    uint64_t mAlign;

    // Real memory addr
    uint64_t mOriAddr;
};

class LoadBlock : public Block {
public:
    ...
private:
    uint64_t mVabitsMask;
    uint64_t mPointMask;
    std::unique_ptr<MemoryMap> mMmap;  // 外部文件映射
    std::unique_ptr<MemoryMap> mOverlay;  // 动态覆盖内存
};

内存引用

正因为都继承了 MemoryRef，在大量重复计算的内存，计算量将会骤减，因为内存引用采用传递的方式来计算，也就是上一个地址已经找到对应的 LoadBlock 后，计算下一个地址若是同一个 Load 段，那么无需再次计算，直接传递上一个内存引用即可。

arduino 复制代码

namespace api {
class MemoryRef {
public:
    ...
private:
    uint64_t vaddr;
    LoadBlock* block;
};
} // namespace api

从计算路径可以知道单个对象最大耗时其实是找 DexFile 这类型地址的过程，需要 4000+ 次判断后才能找到，而新架构上设计内存引用后，如：

kotlin 复制代码

class ArtField : public api::MemoryRef {
public:
    ...
private:
    // quick memoryref cache
    DexFile dex_file_cache = 0x0;
};

新旧架构计算性能差异

前言

对象计算路径

旧架构

新架构

虚实绑定

内存引用