如题所述
实际上V8的JIT编译器是直接在内存中生成机器码的，并不会先生成文本形式的汇编然后再使用汇编器去转换为机器码。“动态生成机器码”听起来可能有点玄乎，其实根本没啥，就是往内存里写字节，这些字节正好是某些机器码的意思，然后把这块内存当作函数去调用就是了。由于代码自身就是动态生成的，在生成的代码里直接嵌入resolve好的各种值其实就相当于传统编译流程里的“动态链接”的效果。顺手放俩我以前博客的传送门：V8实际上自带一个用C++实现的“汇编器库”用来动态生成机器码。它并不把文本形式的汇编转换为机器码，而是提供一组C++ API，调用这个API的函数就可以在内存里生成机器码来。有兴趣的同学可能会知道，V8的MacroAssembler库源自Animorphic的Strongtalk VM，而Strongtalk VM也是HotSpot JVM的前辈。V8 Design Elements文档里所描述的是最初期的V8的状态。当时的V8只有一个JIT编译器，一个JavaScript函数通常只会被JIT编译一次。这个JIT编译器做的优化也不是很多。后来V8演化为拥有两个JIT编译器，一个初级编译器（baseline compiler，名字叫做Full Code Generator，简称FullCodeGen），和一个优化编译器（optimizing compiler，名字叫做Crankshaft），两个编译器结合在一次构成双层编译。JavaScript函数通常会先被FullCodeGen编译，然后如果还继续执行很多次的话则会再被Crankshaft重新编译一遍，生成更优化的代码。在这个架构中，FullCodeGen里生成的代码还是跟V8 Design Elements的相似，会通过inline cache来实现property access；而这些inline cache不但用于实现fast property access，更重要的是它们会被用于收集profile，然后等到Crankshaft编译的时候，它就可以看先前收集的profile来做profile-guided optimization。以这个 function foo(p) { return p.x } 为例，参数p没有任何特别的地方，所以JavaScript引擎也无法知道p到底可能有怎样的值。但通过FullCodeGen生成的代码所收集到的profile信息，Crankshaft再去编译 foo() 的时候就可以知道p之前通常指向一个Map（hidden class）为0x2c97ccb179d1的类型的对象。这个类型的constructor为Point、[[Prototype]] 为Point.prototype、对象里有足够空间容纳10个内嵌的字段（in-object property），并且其中2个slot被用于存储Smi类型，剩余的8个slot未被使用。
什么是上下文（Contexts）？实际是JS应用程序的运行环境，避免应用程序的修改相互影响，例如一个页面js修改内置对象方法toString，不应该影响到另外页面。chrome浏览器每个process只有一个V8引擎实例，浏览器中的每个窗口、iframe都对应一个上下文。V8启动时（在执行client js前），需要对全局上下文(第一个context)初始化，读取和解析自实现的内置JS代码（另一种技术，第2点），建立起function、array、string等内置对象及方法（参见bootstrapper中的Genesis类）；后续context的创建只需要创建内置对象即可；为了减少全局上下文创建时的CPU、内存消耗，V8使用了Snapshot技术（参见v8_mksnapshot工程），（1）全局上下文初始化后，将目前堆内存序列化为字节代码，保存至磁盘文件；这个过程最重要的是空间地址和对象保存，具体操作（参见serialize文件）是：模拟线性内存空间的分配，遍历堆内存中的所有JS对象，并在模拟空间分配内存（实际是记录对象相对偏移地址），然后序列化对象大小、偏移地址、子对象、对象内容；最后是序列化global handler和stack上的context；（2）加载时，将该snapshot文件反序列化进内存，避免第一个上下文初始化，从而加快V8的启动。
