关于javascript:Objects-in-v8

图片起源：siliconangle.com

本文作者：hsy

前言

文本将和大家一起简略理解一下 v8 外部是如何解决对象的，以及 v8 为了高速化对象属性的拜访所做的一些优化的细节。除了联合现有的材料外，本文还链接了一些实现所对应的源码地位，以节约大家后续须要联合源码进行深刻时所花的工夫

本文的目标是理解 v8 的外部实现细节，大家能够依据本人的状况来决定是否须要先浏览上面的材料：

• A tour of V8: object representation
• Fast properties in V8

TaggedImpl

在 v8 外部实现中，所有对象都是从 TaggedImpl 派生的

下图是 v8 中波及 Object 实现的局部类的继承关系图示：

TaggedImpl 所形象的逻辑是「打标签」，所以咱们须要进一步理解「标签」的含意

v8 的 GC 是「精确式 GC，Precise GC」，与之绝对的是「激进式 GC，Conservative GC」

GC 的工作就是帮忙咱们主动治理堆上的内存。当一个对象被 GC 辨认为垃圾对象之后，GC 就须要对其占用的内存进行回收，随之而来的问题是 GC 如何判断指针和非指针，因为咱们晓得对象的属性可能是值属性、或者援用堆上的其余内容（指针）：

type Object = Record<string, number>;
const obj = {field1: 1};

下面的代码咱们通过 Record 来模仿对象的数据结构，其实就是简略的键值对。不过咱们把值都定义成了 number 类型，这是因为对于值类型，咱们间接寄存它们的值就能够了，而对于援用类型，咱们则寄存它们的内存地址，而内存地址也是值，所以就都用 number 示意了

激进式 GC 的劣势是与利用之间的耦合性很低，为了达到这样的设计目标，就要让 GC 尽可能少的依赖利用提供的信息，后果就是 GC 无奈精确判断某个值示意的是指针还是非指针。比方下面的例子，激进式 GC 无奈精确晓得 field1 的值 1 是示意数值，还是指针

当然激进式 GC 并不是齐全不能辨认指针，它能够依据利用具体的应用内存时的行为特点（所以也并不是齐全解耦），对指针和非指针进行猜想。简略来说就是硬编码一些猜想的逻辑，比方咱们晓得利用中的一些确定行为，那么咱们就不必和利用交互，间接把这部分逻辑硬编码到 GC 实现中就能够了。比方咱们晓得身份证的编码格局，如果要验证一串数字是不是身份证，咱们能够依据编码格局来验证，也能够调用公安的 API（如果有的话），前者就是激进式 GC 的工作形式，能够验证出一部分，然而对于那些合乎格局、但却不存在的号码，则也会被辨认为身份证

咱们晓得如果一个内存地址被意外开释，那么肯定会导致利用后续进入谬误的状态、甚至解体。激进式 GC 为了应答这个问题，当它在标记流动对象时，会把看起来像是指针的地址都标记为流动的，这样就不会产生内存被意外开释的问题了，「激进式」之名也因而而得。不过随之而来的是，某些可能曾经是垃圾的对象存活了下来，因而激进式 GC 存在压迫堆的危险

v8 的 GC 是精确式 GC，精确式 GC 就须要和利用进行紧密配合了，TaggedImpl 就是为了配合 GC 辨认指针和非指针而定义的。TaggedImpl 应用的是称为 pointer tagging 的技术（该技术在 Pointer Compression in V8 有提及）

pointer tagging 技术简略来说，就是利用地址都是按字长对齐（字长的整数倍）的个性。这个个性是这样来的：

1. 首先 CPU 的字长因为硬件设计上的考量，都是偶数
2. 而后晚期 CPU 因为外部设计的起因，对偶数地址的寻址的效率要高于对基数地址寻址的效率（不过因为硬件设计上的降级，目前来看也并非相对了）
3. 所以大家（编译器，运行时的内存调配）都会确保地址是按字长对齐的

这样连续到当初，根本就当成一个默认规定了。基于这个规定，因为偶数的最低二进制位是 0，所以 v8 中：

• 对于数值对立左移一位，这样数值的最低二进制位为 0
• 对于指针则将最低二进制地位为 1

比方，对于 GC 而言，0b110 示意的是数值 0b11（应用时需右移一位），对于 0b111 示意的是指针 0b110（寻址时需减 1）。

通过打标签的操作，GC 就能够认为，如果某个地址最低二进制位是 0 则该地位就是 Smi – small integer，否则就是 HeapObject

能够参考 垃圾回收的算法与实现 一书来更加零碎的理解 GC 实现的细节

Object

Object 在 v8 外部用于示意所有受 GC 治理的对象

上图演示了 v8 运行时的内存布局，其中：

• stack 示意 native 代码（cpp 或 asm）应用的 stack
• heap 示意受 GC 治理的堆
• native 代码通过 ptr_ 来援用堆上的对象，如果是 smi 则无需拜访 GC 的堆
• 如果要操作堆上对象的字段，则需进一步通过在对象所属的类的定义中、硬编码的偏移量来实现

各个类中的字段的偏移量都定义在 field-offsets-tq.h 中。之所以要手动硬编码，是因为这些类的实例内存须要通过 GC 来调配，而是不是间接应用 native 的堆，所以就不能利用 cpp 编译器主动生成的偏移量了

咱们通过一个图例来解释一下编码方式（64bit 零碎）：

• 图中通过不同的色彩示意对象本身定义的区域和继承的区域
• Object 中没有字段，所以 Object::kHeaderSize 是 0
• HeapObject 是 Object 类的子类，因而它的字段偏移起始值是 Object::kHeaderSize（参考代码），HeapObject 只有一个字段偏移 kMapOffset 值等于 Object::kHeaderSize 即 0，因为该字段大小是 kTaggedSize（在 64bit 零碎上该值为 8），所以 HeapObject:kHeaderSize 是 8bytes
• JSReceiver 是 HeapObject 类的子类，因而它的字段偏移起始值是 HeapObject:kHeaderSize（参考代码），JSReceiver 也只有一个字段偏移 kPropertiesOrHashOffset，其值为 HeapObject:kHeaderSize 即 8bytes，因为该字段大小是 kTaggedSize，所以 JSReceiver::kHeaderSize 为 16bytes（加上了继承的 8bytes）
• JSObject 是 JSReceiver 的子类，因而它的字段偏移起始值是 JSReceiver::kHeaderSize（参考代码）, JSObject 也只有一个字段偏移 kElementsOffset，值为 JSReceiver::kHeaderSize 即 16bytes，最初 JSObject::kHeaderSize 就是 24bytes

依据下面的剖析后果，最终通过手动编码实现的继承后，JSObject 中一共有三个偏移量：

• kMapOffset
• kPropertiesOrHashOffset
• kElementsOffset

这三个偏移量也就示意 JSObject 有三个内置的属性：

• map
• propertiesOrHash
• elements

map

map 个别也称为 HiddenClass，它形容了对象的元信息，比方对象的大小（instance_size）等等。map 也是继承自 HeapObject，因而它自身也是受 GC 治理的对象，JSObject 中的 map 字段是指向堆上的 map 对象的指针

咱们能够联合 map 源码中正文的 Map layout 和下图来了解 map 的内存的拓扑模式：

propertiesOrHash，elements

在 JS 中，数组和字典在应用上没有显著的差异，然而从引擎实现的角度，在其外部为数组和字典抉择不同的数据结构能够优化它们的访问速度，所以别离应用 propertiesOrHash 和 elements 两个属性就是这个目标

对于命名属性（named properties）会关联到 propertiesOrHash，对于索引属性（indexed properties）则关联到 elements。之所以应用「关联」一词，是因为 propertiesOrHash 和 elements 只是指针，引擎会依据运行时的优化策略，将它们连贯到堆上的不同的数据结构

咱们能够通过上面的图来演示 JSObject 在堆上的可能的拓扑模式：

须要阐明的是，v8 的分代式 GC 会对堆按对象的活跃度和用处进行划分，所以 map 对象理论会放到专门的堆空间中（所以理论会比上图显得更有组织），不过并不影响上图的示意

inobject、fast

下面咱们介绍到 named properties 会关联到对象的 propertiesOrHash 指针指向的数据结构，而用于存储属性的数据结构，v8 并不是间接抉择了常见的 hash map，而是内置了 3 种关联属性的模式：

• inobject
• fast
• slow

咱们先来理解 inobject 和 fast 的模式，上面是它们的整体图示：

inobject 就和它的名字一样，示意属性值对应的指针间接保留在对象结尾的间断地址内，它是 3 种模式中访问速度最快的（依照 fast-properties 中的形容）

留神察看上图中的 inobject_ptr_x，它们只是指向属性值的指针，因而为了依照名称找到对应的属性，须要借助一个名为 DescriptorArray 的构造，这个构造中记录了：

• key，字段名称
• PropertyDetails，示意字段的元信息，比方 IsReadOnly、IsEnumerable 等
• value，只有常量时才会存入其中，如果是 1 示意该地位未被应用（能够联合上文的标签进行了解）

为了拜访 inobject 或者 fast 属性（相干实现在 LookupIterator::LookupInRegularHolder）：

1. v8 须要先依据属性名，在 DescriptorArray 中搜寻到属性值在 inobject array（inobject 因为是间断的内存地址，所以能够看成是数组）或者 property array（图中最右边）中的索引
2. 而后联合数组首地址与指针偏移、拿到属性值的指针，再通过属性值的指针，拜访具体的属性值（相干实现在 JSObject::FastPropertyAtPut）

inobject 相比 fast 要更快，这是因为 fast 属性多了一次间接寻址：

1. inobject 属性晓得了其属性值的索引之后，间接依据对象的首地址进行偏移即可（inobject array 之前的 map_ptr，propertiesOrHash_ptr，elements_ptr 是固定的大小）
2. 而如果是 fast，则须要先在对象的首地址偏移 kPropertiesOrHashOffset 拿到 PropertyArray 的首地址，而后在基于该首地址再进行索引的偏移

因为 inobject 是访问速度最快的模式，所以在 v8 中将其设定为了默认模式，不过须要留神的是 fast 和 inobject 是互补的，只是默认状况下，增加的属性优先按 inobject 模式进行解决，而当遇到上面的情景时，属性会被增加到 fast 的 PropertyArray 中：

• 当整体 inobject 属性的数量超过肯定下限时
• 当动静增加的属性超过 inobject 的预留数量时
• 当 slack tracking 实现后

v8 在创建对象的时候，会动静地抉择一个 inobject 数量，记为 expected_nof_properties（前面会介绍），而后以该数量联合对象的外部字段（比方 map_ptr 等）数来创建对象

初始的 inobject 数量总是会比以后理论所需的尺寸大一些，目标是作为后续可能动静增加的属性的缓冲区，如果后续没有动静增加属性的动作，那么势必会造成空间的节约，这个问题就能够通过前面介绍的 slack tracking 来解决

比方：

class A {b = 1;}

const a = new A();
a.c = 2;

在为 a 调配空间时，尽管 A 只有 1 个属性 b，然而 v8 抉择的 expected_nof_properties 值会比理论所需的 1 大。因为 JS 语言的动态性，多调配的空间能够让后续动静增加的属性也能享受 inobject 的效率，比方例子中的 a.c = 2，c 也是 inobject property，只管它是后续动静增加的

slow

slow 相比 fast 和 inobject 更慢，是因为 slow 型的属性拜访无奈应用 inline cache 技术进行优化，跟多对于 inline cache 的细节能够参考：

• Inline caching
• Explaining JavaScript VMs in JavaScript – Inline Caches

slow 是和 inobject、fast 互斥的，当进入 slow 模式后，对象内的属性构造如下：

slow 模式不再须要上文提到的 DescriptorArray 了，字段的信息对立都寄存在一个字典中

inobject 下限

上文提到 inobject properties 的数量是有下限的，其计算过程大抵是：

// 为了不便计算，这里把波及到的常量定义从源码各个文件中摘出后放到了一起
#if V8_HOST_ARCH_64_BIT
constexpr int kSystemPointerSizeLog2 = 3;
#endif
constexpr int kTaggedSizeLog2 = kSystemPointerSizeLog2;
constexpr int kSystemPointerSize = sizeof(void*);

static const int kJSObjectHeaderSize = 3 * kApiTaggedSize;
STATIC_ASSERT(kHeaderSize == Internals::kJSObjectHeaderSize);

constexpr int kTaggedSize = kSystemPointerSize;
static const int kMaxInstanceSize = 255 * kTaggedSize;
static const int kMaxInObjectProperties = (kMaxInstanceSize - kHeaderSize) >> kTaggedSizeLog2;

依据下面的定义，在 64bit 零碎上、未开启指针压缩的状况下，最大数量是 252 = (255 * 8 - 3 * 8) / 8

allow-natives-syntax

为了前面能够通过代码演示，这里须要交叉介绍一下 --allow-natives-syntax 选项，该选项是 v8 的一个选项，开启该选项后，咱们能够应用一些公有的 API，这些 API 能够不便理解引擎运行时的外部细节，最后是用于 v8 源码中编写测试案例的

// test.js
const a = 1;
%DebugPrint(a);

通过命令 node --allow-natives-syntax test.js 即可运行下面的代码，其中 %DebugPrint 就是 natives-syntax，而 DebugPrint 则是公有 API 中的一个

更多的 API 能够在 runtime.h 中找到，它们具体的用法令能够通过搜寻 v8 源码中的测试案例来理解。另外，DebugPrint 对应的实现在 objects-printer.cc 中

下面的代码运行后显示的内容相似：

DebugPrint: Smi: 0x1 (1) # Smi 咱们曾经在上文介绍过了

构造函数创立

上文提到 v8 创建对象的时候，会动静抉择一个预期值，该值作为 inobject 属性的初始数量，记为 expected_nof_properties，接下来咱们看下该值是如何抉择的

在 JS 中有两种次要的创建对象的形式：

• 从构造函数创立
• 对象字面量

咱们先看从构造函数创立的状况

将字段作为 inobject properties 的技术并不是 v8 独创的，在动态语言的编译中，是常见的属性解决计划。v8 只是将其引入到 JS 引擎的设计中，并针对 JS 引擎做了一些调整

从构造函数创立的对象，因为在编译阶段就能 大抵 取得属性的数量，所以在调配对象的时候，inobject 属性数就能够借助编译阶段收集的信息：

function Ctor1() {
  this.p1 = 1;
  this.p2 = 2;
}

function Ctor2(condition) {
  this.p1 = 1;
  this.p2 = 2;
  if (condition) {
    this.p3 = 3;
    this.p4 = 4;
  }
}

const o1 = new Ctor1();
const o2 = new Ctor2();

%DebugPrint(o1);
%DebugPrint(o2);

「大抵」的含意就是，对于下面的 Ctor2 会认为它有 4 个属性，而不会思考 condition 的状况

咱们能够通过运行下面的代码来测试：

DebugPrint: 0x954bdc78c61: [JS_OBJECT_TYPE]
 - map: 0x0954a8d7a921 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x0954bdc78b91 <Object map = 0x954a8d7a891>
 - elements: 0x095411500b29 <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x095411500b29 <FixedArray[0]> {#p1: 1 (const data field 0)
    #p2: 2 (const data field 1)
 }
0x954a8d7a921: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 104
 - inobject properties: 10
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 8
 - enum length: invalid
 - stable_map
 - back pointer: 0x0954a8d7a8d9 <Map(HOLEY_ELEMENTS)>
 - prototype_validity cell: 0x0954ff2b9459 <Cell value= 0>
 - instance descriptors (own) #2: 0x0954bdc78d41 <DescriptorArray[2]>
 - prototype: 0x0954bdc78b91 <Object map = 0x954a8d7a891>
 - constructor: 0x0954bdc78481 <JSFunction Ctor1 (sfi = 0x954ff2b6c49)>
 - dependent code: 0x095411500289 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>

下面代码会输入两段 DebugPrint，下面为其中的第一段：

• 紧接着 DebugPrint: 打印的是咱们传入的对象 o1
• 随后的 0x954a8d7a921: [Map] 是该对象的 map 信息
• 咱们曾经介绍过 map 是对象的元信息，因而诸如 inobject properties 都记录在其中
• 下面的 inobject properties 是 10 = 2 + 8，其中 2 是编译阶段收集到的属性数，8 是额定预调配的属性数
• 因为对象 header 中总是有指向 map、propertiesOrHash、elements 的三个指针，所以整个对象的大小（instance size）就是 headerSize + inobject_properties_size 即 104 = (3 + (2 + 8)) * 8

大家能够依据下面的过程验证下 %DebugPrint(o2) 的输入

空构造函数

为了防止大家在试验的过程中产生纳闷，上面再解释一下空构造函数时调配的对象大小：

function Ctor() {}
const o = new Ctor();
%DebugPrint(o);

下面的打印结果显示 inobject properties 数量也是 10，依照前文的计算过程，因为编译阶段发现该构造函数并没有属性，数量应该是 8 = 0 + 8 才对

之所以显示 10 是因为，如果编译阶段发现没有属性，那么默认也会给定一个数值 2 作为属性的数量，这么做是基于「大部分构造函数都会有属性，以后没有可能是后续动静增加」的假设

对于下面的计算过程，能够通过 shared-function-info.cc 进一步探索

Class

上文咱们都是间接将函数对象当做构造函数来应用的，而 ES6 中早已反对了 Class，接下来咱们来看下应用 Class 来实例化对象的状况

其实 Class 只是一个语法糖，JS 语言规范对 Class 的运行时语义定义在 ClassDefinitionEvaluation 一节中。简略来说就是同样会创立一个函数对象（并设置该函数的名称为 Class 名），这样随后咱们的 new Class 其实和咱们 new FunctionObject 的语义统一

function Ctor() {}
class Class1 {}

%DebugPrint(Ctor);
%DebugPrint(Class1);

咱们能够运行下面的代码，会发现 Ctor 和 Class1 都是 JS_FUNCTION_TYPE

咱们之前曾经介绍过，初始的 inobject properties 数量会借助编译时收集的信息，所以上面的几个模式是等价的，且 inobject properties 数量都是 11（3 + 8）：

function Ctor() {
  this.p1 = 1;
  this.p2 = 2;
  this.p3 = 3;
}
class Class1 {
  p1 = 1;
  p2 = 2;
  p3 = 3;
}
class Class2 {constructor() {
    this.p1 = 1;
    this.p2 = 2;
    this.p3 = 3;
  }
}
const o1 = new Ctor();
const o2 = new Class1();
const o3 = new Class2();
%DebugPrint(o1);
%DebugPrint(o2);
%DebugPrint(o3);

在编译阶段的收集的属性数称为「预估属性数」，因为其只需提供预估的精度，所以逻辑很简略，在解解析函数或者 Class 定义的时候，发了一个设置属性的语句就让「预估属性数」累加 1。上面的模式是等价的，都会将「预估属性数」辨认为 0 而造成 inobject properties 初始值被设定为 10（上文有讲道过，当 estimated 为 0 时，总是会调配固定的个数 2，再加上预调配 8，会让初始 inobject 数定成 10）：

function Ctor() {}

// babel runtime patch
function _defineProperty(obj, key, value) {if (key in obj) {
    Object.defineProperty(obj, key, {
      value: value,
      enumerable: true,
      configurable: true,
      writable: true,
    });
  } else {obj[key] = value;
  }
  return obj;
}

class Class1 {constructor() {_defineProperty(this, "p1", 1);
    _defineProperty(this, "p2", 2);
    _defineProperty(this, "p3", 3);
  }
}

const o1 = new Ctor();
const o2 = new Class1();
%DebugPrint(o1);
%DebugPrint(o2);

Class1 构造函数中的 _defineProperty 对于目前的预估逻辑来说太简单了，预估逻辑设计的简略并不是因为从技术上不能剖析下面的例子，而是因为 JS 语言的动态性，与为了放弃启动速度（也是动静语言的劣势）让这里不太适宜应用过重的动态剖析技术

_defineProperty 的模式其实是 babel 目前编译的后果，联合前面会介绍的 slack tracking 来说，即便这里预估数不合乎咱们的预期，但也不会有太大的影响，因为咱们的单个类的属性个数超过 10 的状况在整个利用中来看也不会是大多数，不过如果咱们思考继承的状况：

class Class1 {
  p11 = 1;
  p12 = 1;
  p13 = 1;
  p14 = 1;
  p15 = 1;
}

class Class2 extends Class1 {
  p21 = 1;
  p22 = 1;
  p23 = 1;
  p24 = 1;
  p25 = 1;
}

class Class3 extends Class2 {
  p31 = 1;
  p32 = 1;
  p33 = 1;
  p34 = 1;
  p35 = 1;
}

const o1 = new Class3();
%DebugPrint(o1);

因为继承模式的存在，很可能通过屡次继承，咱们的属性数会超过 10。咱们打印下面的代码，会发现 inobject properties 是 23（15 + 8），如果通过 babel 编译，则代码会变成：

"use strict";

function _defineProperty(obj, key, value) {if (key in obj) {Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true}); } else {obj[key] = value; } return obj; }

class Class1 {constructor() {_defineProperty(this, "p11", 1);
    _defineProperty(this, "p12", 1);
    _defineProperty(this, "p13", 1);
    _defineProperty(this, "p14", 1);
    _defineProperty(this, "p15", 1);
  }
}

class Class2 extends Class1 {constructor(...args) {super(...args);

    _defineProperty(this, "p21", 1);
    _defineProperty(this, "p22", 1);
    _defineProperty(this, "p23", 1);
    _defineProperty(this, "p24", 1);
    _defineProperty(this, "p25", 1);
  }
}

class Class3 extends Class2 {constructor(...args) {super(...args);

    _defineProperty(this, "p31", 1);
    _defineProperty(this, "p32", 1);
    _defineProperty(this, "p33", 1);
    _defineProperty(this, "p34", 1);
    _defineProperty(this, "p35", 1);
  }
}

const o1 = new Class3();
%DebugPrint(o1);

下面的 inobject properties 数量只有 14 个，起因是 Class3 的 inobject 属性数预估值、还须要加上其先人类的 inobject 属性数的预估值，其两个先人类的预估值都是 2（因为编译期没有收集到数量而默认调配的固定数量 2），因而 Class3 的 inobject 属性预估值就是 6 = 2 + 2 + 2，加上额定调配的 8 个，最初是 14 个

而咱们理论的属性数量是 15 个，这就导致第 15 个属性 p35 被调配成了 fast 型，回顾没有通过 babel 编译的代码，所有属性都会是 inobject 型的

最后发现 babel 和 tsc 的编译后果不同，后者未应用 _defineProperty 的模式，认为是 babel 编译实现有瑕疵。前面发现 babel 的后果其实是规范中规定的行为，见 Public instance fields – 实例字段是应用 Object.defineProperty 增加的。对于 tsc 来说，开启 useDefineForClassFields 后能够达到雷同的编译后果（在目前的 deno-v1.9 中这个选项被默认开启了）

原本是想说大家能够抉择 tsc 的，但当初看来在一些对性能有极致要求的场景下，防止引入编译环节或者是最好的办法

从对象字面量创立

const a = {p1: 1};
%DebugPrint(a);

运行下面的代码，会发现 inobject properties 数量是 1，这里没有 8 个的预留空间，是因为从对象字面量创立通过的是 CreateObjectLiteral 办法，其外部没有预留空间的策略，而是 间接应用 编译收集的信息，这与从构造函数创立通过的 JSObject::New 办法外部的策略不同

从对象字面量创立会应用字面量中的属性数作为 inobject properties 的数量，因而后续增加的属性会是 fast 型

空对象字面量

和空构造函数的状况相似，空对象字面量的大小也须要另外探讨：

const a = {};
%DebugPrint(a);

运行下面的代码，会发现 inobject properties 数量是 4，这是因为：

• CreateObjectLiteral 内会调用 Factory::ObjectLiteralMapFromCache
• Factory::ObjectLiteralMapFromCache 的逻辑是，当空字面量时，应用 object_function().initial_map() 来做成创建对象的模板
• object_function() 本身的创立在 Genesis::CreateObjectFunction 中，其中的 kInitialGlobalObjectUnusedPropertiesCount 是 4

所以 4 是一个硬编码的值，当创立空对象的时候，就应用该值作为初始的 inobject properties 的数量

另外 CreateObjectLiteral 源码中也 提及，如果应用 Object.create(null) 创立的对象，则间接是 slow 模式

inobject、fast、slow 之切换

inobject、fast、slow 三种模式的存在，是基于分而治之的理念。对有动态性的场景（比方构造函数创立），则实用 inobject、fast，对动态性的局部，则实用 slow。上面咱们来简略看一下三者之间的切换条件

1. 在 inobject 配额足够的状况下，属性优先被当成 inobject 型的
2. 当 inobject 配个有余的状况下，属性被当成是 fast 型的
3. 当 fast 型的配额也有余的状况下，对象整个切换成 slow 模式
4. 两头某一步骤中，执行了 delete 操作删除属性（除了删除最初一个顺位的属性以外，删除其余顺位的属性都会）让对象整个切换成 slow 模式
5. 如果某个对象被设置为另一个函数对象的 property 属性，则该对象也会切换成 slow 模式，见 JSObject::OptimizeAsPrototype
6. 一旦对象切换成 slow 模式，从开发者的角度，就根本能够认为该对象不会再切换成 fast 模式了（尽管引擎外部的一些非凡状况下会应用 JSObject::MigrateSlowToFast 切换回 fast）

下面的切换规定看起来如同很繁琐（并且也可能并不是全副状况），但其实背地的思路很简略，inobject 和 fast 都是「偏动态」的优化伎俩，而 slow 则是齐全动静的模式，当对象频繁地动静增加属性、或者执行了 delete 操作，则预测它很可能将来还会频繁的变动，那么应用纯动静的模式可能会更好，所以切换成 slow 模式

对于 fast 型的配额咱们能够略微理解一下，fast 型是寄存在 PropertyArray 中的，这个数组以每次 kFieldsAdded（以后版本是 3）的步长裁减其长度，目前有一个 kFastPropertiesSoftLimit（以后是 12）作为其 limit，而 Map::TooManyFastProperties 中应用的是 >，所以 fast 型目前的配额最大是 15

大家能够应用上面的代码测试：

const obj = {};
const cnt = 19;
for (let i = 0; i < cnt; i++) {obj["p" + i] = 1;
}
%DebugPrint(obj);

别离设置 cnt 为 4，19 和 20，会失去相似上面的输入：

# 4
DebugPrint: 0x3de5e3537989: [JS_OBJECT_TYPE]
 #...
 - properties: 0x3de5de480b29 <FixedArray[0]> {

#19
DebugPrint: 0x3f0726bbde89: [JS_OBJECT_TYPE]
 #...
 - properties: 0x3f0726bbeb31 <PropertyArray[15]> {

# 20
DebugPrint: 0x1a98617377e1: [JS_OBJECT_TYPE]
 #...
 - properties: 0x1a9861738781 <NameDictionary[101]>

• 下面的输入中，当应用了 4 个属性时，它们都是 inobject 型的 FixedArray[0]
• 当应用了 19 个属性时，曾经有 15 个属性是 fast 型 PropertyArray[15]
• 当应用了 20 个属性时，因为超过了下限，对象整体切换成了 slow 型 NameDictionary[101]

至于为什么 inobject 显示的是 FixedArray，只是因为当没有应用到 fast 型的时候 propertiesOrHash_ptr 默认指向了一个 empty_fixed_array，有趣味的同学能够通过浏览 property_array 来确认

slack tracking

前文咱们提到，v8 中的初始 inobject 属性的数量，总是会多调配一些，目标是让后续可能通过动静增加的属性也能够成为 inobject 属性，以享受到其带来的快速访问效率。然而多调配的空间如果没有被应用肯定会造成节约，在 v8 中是通过称为 slack tracking 的技术来进步空间利用率的

这个技术简略来说是这样实现的：

• 构造函数对象的 map 中有一个 initial_map() 属性，该属性就是那些由该构造函数对象创立的模板，即它们的 map
• slack tracking 会批改 initial_map() 属性中的 instance_size 属性值，该值是 GC 分配内存空间时应用的
• 当第一次应用某个构造函数 C 创建对象时，它的 initial_map() 是未设置的，因而首次会设置该值，简略来说就是创立一个新的 map 对象，并设置该对象的 construction_counter 属性，见 Map::StartInobjectSlackTracking
• construction_counter 其实是一个递加的计数器，初始值是 kSlackTrackingCounterStart 即 7
• 随后每次（包含当次）应用该构造函数创建对象，都会对 construction_counter 递加，当计数为 0 时，就会汇总以后的属性数（包含动静增加的），而后失去最终的 instance_size
• slack tracking 实现后，后续动静增加的属性都是 fast 型的

construction_counter 计数的模式相似下图：

slack tracking 是依据结构函数调用的次数来的，所以应用对象字面量创立的对象无奈利用其进步空间利用率，这也侧面阐明了上文提到的空字面量的创立，默认预调配的是 4 个而不像构造函数创立那样预留 8 个（因为无奈利用 slack tracking 后续进步空间利用率，所以只能在开始的时候就节流）

能够通过 Slack tracking in V8 进一步理解其实现的细节

小结

咱们能够将上文的重点局部小结如下：

• 对象的属性有三种模式：inobject，fast，slow
• 三种模式的属性拜访效率由左往右递加
• 属性默认应用 inobject 型，超过预留配额后，持续增加的属性属于 fast 型
• 当持续超过 fast 型的配额后，对象整个切换到 slow 型
• 初始 inobject 的配额会因为应用的是「构造函数创立」还是「对象字面量」创立而不同，前者依据编译器收集的信息（大抵属性数 + 8，且下限为 252），后者是固定的 4
• 应用 Object.create(null) 创立的对象间接是 slow 型
• 对于任意对象 A，在其申明周期内，应用 delete 删除了除最初顺位以外的其余顺位的属性，或者将 A 设置为另一个构造函数的 prototype 属性，都会将对象 A 整个切换为 slow 型
• 目前来看，切换到 slow 型后将不能再回到 fast 型

在理论应用时，咱们不用思考下面的细节，只有确保在有条件的状况下：

• 尽可能应用构造函数的形式创建对象，换句话说是尽可能的缩小属性的动态创建。实际上，像这样尽可能让 JS 代码体现出更多的动态性，是投合引擎外部优化形式以取得更优性能的外围准则，同样的操作包含尽可能的放弃变量的类型始终惟一、以防止 JIT 生效等
• 如果须要大量的动静增加属性，或者须要删除属性，间接应用 Map 对象会更好（尽管引擎外部也会主动切换，然而间接用 Map 更合乎这样的场景，也省去了外部切换的耗费）

本文简略联合源码介绍了一下 v8 中是如何解决对象的，心愿能够有幸作为大家深刻理解 v8 内存治理的初始读物

参考资料

• 垃圾回收的算法与实现
• A tour of V8: object representation
• V8 引擎 JSObject 构造解析和内存优化思路
• Fast properties in V8
• Pointer Compression in V8
• Slack tracking in V8

本文公布自 网易云音乐大前端团队，文章未经受权禁止任何模式的转载。咱们长年招收前端、iOS、Android，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe (at) corp.netease.com！