Z

V8 Heap Snapshot 格式解析

查看页面堆内存使用情况时,DevTools 的 Memory 面板是最核心的工具。

但在超大型前端工程中,有些场景使用 Memory 面板定位堆内存使用情况是不太方便的,典型场景例如:

  • 堆内存字符串常量池中有上百万个字符串,这些字符串可能被不同的对象持有,在 Memory 面板中无法知道这些字符串持有对象的分布。
  • 一次只能查看一条持有链,例如上图中 Object@194053 可以看到被谁持有,以及持有谁,但都是以 Object@194053 为核心的,如果有一个较大的循环引用,往往很难发现
  • 没有方便的过滤、排序选项

但所幸 DevTools 支持将堆内存快照保存为文本格式,点击保存按钮就会保存当前快照为 *.heapsnapshot 文件,这就使我们编写自定义分析程序成为可能,分析的第一步就是要了解并解析 heapsnapshot 文件中的关键数据。

堆内存结构

在开始分析文件结构前,先简单了解下堆内存的结构。

上图是视觉上的堆内存表示,堆内存中一个对象有两种方式来占用一些内存:

  • 对象自身直接占用内存
  • 对象持有别的对象,使别的对象无法被 GC 掉,从而间接占用内存

对象之间可以互相引用,不论是通过属性链接到另一个对象上,还是将另一个对象存在自己的数组里,本质上都是建立了对象之间的引用关系,这些引用关系就如同上图一样,所以堆内存结构本质上就是一张 “有向图”,我们解析 heapsnapshot 文件就是要把这张 “有向图” 从数据中发掘出来。

heapsnapshot 文件结构

heapsnapshot 是纯文本文件,可以直接使用文本编辑器打开。打开后可以看到它其实是一份 JSON 文档。

既然是 JSON 文档,那就能用 JS 直接读它并在 DevTools 里查看:

1const [fh] = await window.showOpenFilePicker();
2const fp = await fh.getFile();
3const reader = new FileReader();
4reader.onload = () => console.log(JSON.parse(reader.result))
5reader.readAsText(fp);

heapsnapshot 文件中核心字段有四个:

  • nodes - 存储所有顶点数据,每一个顶点是堆内存中最小的原子结构
  • edges - 存储所有边的数据,边连接两个顶点
  • snapshot - 这份 snapshot 文件的元数据,包含顶点数量、边数量、顶点字段类型、边字段类型等
  • strings - 所有字符串数据,例如顶点名称,类型名称等

nodes

首先看一下 nodes 序列化时的结构,从 HeapSnapshotJSONSerializer::SerializeNode

方法中可以看到,V8 会把每个顶点的7个属性按顺序保存下来,也就是说在 nodes 数组中,每 7 个值属于一个顶点,他们的值都是数字,却有不同的含义。 snapshot.node_count * snapshot.meta.node_types.length 的结果正是 nodes.length

这7个属性值分别是

  • type - 节点类型,它是 snapshot.meta.node_types[0] 的索引
  • name - 节点名称,它是 strings 的索引
  • id - 节点 id, 这个 id 是 V8 Snapshot 对象的id,也就是上图中 Object@194053 @ 后面的值,该 id 在一个 V8 实例中全局唯一
  • self_size - 节点自身尺寸
  • edge_count - 起点为该节点的边的数量
  • trace_node_id - 可以暂时不管,正常方式启动 Chromium/Chrome 后该字段值始终为 0,只有启动时带上参数 --track-heap-objects 才不为0,用于定位该对象创建的调用栈
  • detachedness - 可以暂时不管,它表示对象是否从主应用中分离(detached),通常都是 0,表示 unknown

看到这里堆 nodes 的结构就很清晰了:

简单的伪代码就是:

 1for node_base_idx in (0..all_nodes.len()).step_by(meta.node_fields.len()) {
 2    nodes.push(Node {
 3        node_type: meta.node_types[0].get_value(all_nodes[node_base_idx] as usize),
 4        name: self.get_string(all_nodes[node_base_idx + 1] as usize),
 5        id: all_nodes[node_base_idx + 2],
 6        self_size: all_nodes[node_base_idx + 3],
 7        edge_count: all_nodes[node_base_idx + 4],
 8        trace_node_id: all_nodes[node_base_idx + 5],
 9        detachedness: all_nodes[node_base_idx + 6],
10    })
11}

node 是 Heap 中的实体的映射,所以 node 会有不同的类型。正如前面提到的,node 的类型存储在 snapshot.meta.node_types 中,它们分别是:

  • hidden: 隐藏类型
  • array: 数组
  • string: 字符串
  • object: 除数组与字符串外的 JavaScript 对象
  • code: 编译后的代码
  • closure: 函数闭包(是的,函数闭包不只是一个语法结构,它也存在于堆内存中)
  • regexp: 正则表达式
  • number: 存储在堆中的数字
  • native: 非 V8 引入的 Native 对象
  • synthetic: 合成对象,通常用于打包多个 snapshot 中的项目
  • concatenated string: 串联的字符串(一对指向字符串的指针)
  • sliced string: 字符串切片(另一个字符串的片段)
  • symbol: ES6 中的 Symbol
  • bigint: BigInt

node name 也与 node type 相关联。前文提到,name 也是 node 上的一个属性,表示这个节点的名称,但 name 属性的真实含义是相对于 node type 的。

  • 如果 node type 为 object,则 node name 为它的 constructor name
  • 如果 node type 为 closure,则 node name 为闭包函数名称
  • 如果 node type 为 string,则 node name 为 string value

edges

看懂了 nodes 的结构,edges 的结构就好理解多了,与 nodes 类型,edges 也是三个值组成一个 edge,这三个值分别是:

  • type - 边的类型,它是 snapshot.meta.edge_types[0] 的索引
  • name_or_index - 边的名称索引或自身索引
    • 如果边的类型为 element 或 hidden,则其值为自身索引,表示目标节点在源节点中的位置
    • 否则就是名称索引,表示边的名称,值为 strings 的索引
  • to_node - 边的目标节点索引

唯一的问题是,heap snapshot 是一张有向图,但 edges 中只记录了一条边的 「终点」(to_node),没有 「起点」(from_node),这样的图是不完整的。那么边与它的起点是如何对应的呢,这需要再看一下 HeapSnapshotGenerator::FillChildren

大致的逻辑是:

  • FillChildren 按顺序遍历每一个 node 时,记录从该 node 出发有多少条边,并输出
  • FillChildren 按顺序遍历每一个 edge 时,并输出

所以 node 与 edge 的关系就是:

  • 每一个 node 的 edge_count 为几,说明它有几条边
  • edges 是 nodes 的映射,node 的 edge_count 时几,在 edges 中就有几条边的起始节点是该 node

例如上图中:

  • node0 的 edge_count 为 3,edges[0..3] 的 from_node 就是 node0
  • node1 的 edge_count 为 1, edges[3] 的 from_node 就是 node1
  • node2 的 edge_count 为 0, edges 中没有起点为 node2 的边
  • node3 的 edge_count 为 1,edges[4] 的 from_node 就是 node3

简单的伪代码就是:

 1let mut edge_from_node_idx = 0;
 2let mut edge_from_node_acc = 0;
 3
 4// 按 edge_fields 的长度,步进解析每一条边
 5for (edge_idx, edge_base_idx) in (0..all_edges.len())
 6    .step_by(meta.edge_fields.len())
 7    .enumerate()
 8{
 9    // 边的基础信息
10    let edge_type = meta.edge_types[0].get_value(all_edges[edge_base_idx] as usize);
11    let edge_name_or_index = self.get_string(all_edges[edge_base_idx + 1] as usize);
12    let edge_to_node_idx = all_edges[edge_base_idx + 2] as usize / nodes_fields_count;
13
14    // 忽略 edge_count 为 0 的节点
15    while nodes[edge_from_node_idx].edge_count == 0 {
16        edge_from_node_idx += 1;
17        edge_from_node_acc = 0;
18    }
19
20    // 设置边的起点/终点
21    let edge_idx = edge_idx as u32;
22    nodes[edge_from_node_idx].to_edge_index.push(edge_idx);
23    nodes[edge_to_node_idx].from_edge_index.push(edge_idx);
24
25    let from_node_id = nodes[edge_from_node_idx].id;
26    let to_node_id = nodes[edge_to_node_idx].id;
27
28    edges.push(Edge {
29        edge_type,
30        name_or_index: edge_name_or_index,
31        to_node_index: edge_to_node_idx,
32        to_node_id,
33        from_node_index: edge_from_node_idx,
34        from_node_id,
35    });
36
37    edge_from_node_acc += 1;
38
39    // 如果当前边的累加值超过 edge_count,则重置累加器,边索引 +1
40    if edge_from_node_acc >= nodes[edge_from_node_idx].edge_count as usize {
41        edge_from_node_idx += 1;
42        edge_from_node_acc = 0;
43    }
44}

edge 是 heap 中两个实体的关系映射,例如对象引用、数组引用等。同样,edge 也有多种类型:

  • context 表示目标来源于一个 function context
  • element 表示目标是一个数组中的元素
  • property 表示目标是一个对象上的属性
  • internal 内部引用,这种引用无法被 JavaScript 访问,例如 concatenated string
  • hidden 这种连接在计算持有尺寸时需要,但不对用户暴露
  • shortcut 这种连接在计算持有尺寸时需要排除
  • weak 弱引用连接