图说 WebAssembly（二）：JIT 编译器

本文是图说 WebAssembly 系列文章的第二篇，若是你还没阅读其它的，建议您从第一篇开始。

JavaScript 的运行，一开始是很慢的，可是后面会变得愈来愈快，背后的功臣就是 JIT 。
可是 JIT 是如何工做的呢？

JS 如何在浏览器中运行

做为开发者，咱们给网页写 JavaScript 代码是有明确目标的，固然也会伴随着问题。

目标：告诉计算机要作什么。
问题：咱们和计算机使用着不一样语言。

咱们使用的是人类语言，而计算机则使用机器语言。
虽然你可能不一样意把 JavaScript 或者其余高级编程语言称为人类语言，但它们也确确实实是人类语言。
由于它们是按照人类认知被设计出来的，而不是机器认知。

因此，JavaScript 引擎的工做就是接收人类语言，而后输出机器语言。
这就像电影《降临》中所描述的同样，人类试图和外星人进行交流。

电影中，人类和外星人的交流并非经过逐个文字翻译来实现的。这两个群体有不一样的世界观，这种差别也一样适用于人类和机器。

那么，人类和机器之间的“翻译”又是怎么实现的呢？

在编程领域，翻译成机器语言有两种通用的方式：解释器和编译器。

使用解释器时，这种翻译几乎是实时且逐行进行的。

而对于编译器，却不是实时的，它须要提早翻译并保存起来。

这两种翻译方式各有利弊。

解释器优缺点

解释器能够快速启动并运行代码。
咱们不须要等待整个编译步骤结束以后才开始运行代码。翻译一行，运行一行。

基于此，解释器看起来很是适合像 JavaScript 这样的语言。由于对于一个互联网开发者来讲，快速开始并运行代码是很是重要的。

这也是为何浏览器从一开始就使用 JavaScript 解释器的缘由。

可是，当须要屡次运行相同代码时，解释器的弊端就凸显出来了。
好比，在一个循环中，解释器得重复的翻译相同的代码。

编译器优缺点

与解释器相比，编译器有着相反的优缺点。

编译器会在开始时耗费比较多的时间，由于他须要经历整个编译过程。不过，一旦编译好，循环中的代码就能够跑得更快，由于它再也不须要重复的翻译相同代码。

另外一个不一样点是，编译器有更多的时间来分析代码，而后修改代码，使它能跑得更快。这个修改过程称为优化。
而解释器就不一样了，它是运行时进行代码翻译的，因此它无法在这个过程当中作优化。

集大成者：JIT 编译器

为了解决解释器重复翻译相同代码低效行为，浏览器开始把编译器引入进来。

不一样浏览器的作法有略微不一样，可是基本作法是相同的。
它们为 JavaScript 引擎新增了一个组件，称为监视器（Monitor，或者 Profiler）。
监视器的工做就是观察代码运行，而后记录代码的运行次数，以及它们使用的数据类型。

最开始时，监视器会观察解释器运行的全部代码。

若是某一处的几行代码运行了好几回，那么该处的几行代码就被标记为暖代码（warm）。
若是运行了很是屡次，那么就会被标记为热代码（hot） 。

基准编译器

当一个函数被标记为暖代码，JIT 就会把它发送给基准编译器（Baseline Compiler）进行编译，并把编译结果保存下来。

函数中的每一行代码都被编译成一个存根（Stub）。这些存根在存储时，使用代码行号和变量类型做为索引。
若是监视器发现相同的代码运行使用的是相同变量类型，那么它会取出已编译好的代码来运行。

能够看出，这已经加快了运行速度。
不过，编译器还能够作得更好。它能够花点时间来分析代码，以便找出最高效的方式，也就是作优化。

基准编译器也是可以作一些优化的（下文会举例说明）。
可是它不能花费太多时间在优化上，由于咱们并不但愿它长时间阻塞代码运行。

优化编译器

当有些代码变成热代码，监视器就会把它发送给优化编译器（Optimizing Compiler）。优化编译器会把它编译成另外一种更快版本的函数，而且保存起来。

为了生成更快的代码，优化编译器必须做出一些前提假设。

好比，若是假设使用特定构造函数建立的对象都有相同的结构，即有相同的属性名而且添加顺序也是一致的，那么优化编译器就能够基于此删除一些代码。

优化编译器会基于监视器记录的代码运行信息来做出一些判断。好比，若是在一个循环中，以前运行时某个变量一直是 true，那么它就会假设它在将来仍然是 true。

固然，在 JavaScript 中，实际上是没有任何保证可言的。
可能以前的 99 个对象都有着相同的结构，可是到第 100 个对象时，它仍可能会缺乏某个属性。

所以，编译后的代码在运行以前须要检查原先的假设是否成立。
若是成立，那么直接运行编译后的代码；若是不成立，那么 JIT 会认为它做出了错误假设，因而它会把优化的代码废弃掉。

而后，代码的运行会返回去使用解释器运行或者采用基准编译器编译的代码。这个过程称为去优化（Deoptimization）。

一般来讲，优化编译器会使得代码跑的更快。不过有时候，它也可能会致使意料以外的性能问题。
若是有一部分代码一直在优化和去优化之间切换，那么它其实比直接使用基准编译器的编译的代码还更慢。

大多数浏览器已经增长了一些限制，来及时打破这种优化/去优化的循环过程。
好比说，当 JIT 尝试了 10 次优化以后仍然发生了去优化，那么它就再也不尝试对其进行优化。

优化举例：类型特定化

有不少种不一样的优化方式，这里咱们只举例说明其中一种，来帮助理解整个优化过程。
在众多优化方式中，类型特定化（Type Specialization）取得的优化是最明显的。

JavaScript 采用的动态类型系统使得代码在运行时须要作些额外的检查工做。
好比，对于如下代码：

function arraySum(arr) {
    var sum = 0;
    for (var i = 0; i < arr.length; i++) {
        sum += arr[i];
    }
}

其中的 += 操做看起来很是简单，彷佛只须要进行一次操做就能完成计算。
可是，由于是动态类型，实际上进行的操做次数远不足一次那么简单。

让咱们假设 arr 是一个包含 100 个整数的数组。一旦该函数被标记为暖代码，基准编译器就会为该函数中的每个操做建立一个存根。因此 sum += arr[i] 也会对应一个存根，它会把 += 操做做为整数加法。

然而，咱们并不能保证 sum 和 arr[i] 都是整数。
由于 JavaScript 中的数据类型是动态的，因此在后续的循环中，arr[i] 可能就变成了字符串。
而整数加法和字符串链接是两种彻底不一样的操做，因此它们会被编译为彻底不一样的机器代码。

对于这种状况，JIT 的处理方式是编译成多种不一样的基准存根。
若是每次调用代码都使用相同的数据类型，那么只会生成一种存根；若是每次调用使用不一样的数据类型，那么会生成每种类型组合起来的存根。

也就意味着，JIT 在选择一个存根以前必须先作好多判断。

由于每一行代码在基准编译器中都会有它本身的存根集合，因此每行代码运行时 JIT 须要一直进行类型判断。所以，在该循环中的每一次遍历，它都要进行相同的类型判断过程。

若是 JIT 不须要每次都重复这些类型判断，那么代码跑起来就会更快。而这正是优化编译器所作的优化之一。

在优化编译器中，整个函数是一块儿编译的。因此能够把类型判断移到循环以前。

一些 JIT 对此作了更深的优化。好比，在 Firefox 中，咱们把只包含整数的数组划分为特殊的数组分类。若是 arr 是这种数组，那么 JIT 就不须要检查 arr[i] 是不是一个整数了。这样的话，JIT 能够在进入循环以前就作完全部的类型判断。

结束

以上就是对 JIT 的简短介绍。
经过监视代码运行，编译热代码等方式，JIT 使得 JavaScript 代码跑的更快。这为大多数 JavaScript 应用带来了许多性能改进。

尽管作了这些优化，可是 JavaScript 的性能可能仍然没法预测。
由于作这些优化的同时，咱们也给运行时增长了额外的开销，包括：

• 优化和去优化过程
• 监视器记录和恢复信息占用的内存
• 用于保存基准、优化后函数的内存

不过，对于这些仍然有改进的空间，咱们能够消除这些额外开销，使得性能提高更具可预测性。
而这就是 WebAssembly 所作的一件事情！

在下一篇文章中，咱们将更详细介绍 WebAssembly ，以及它是如跟编译器一块儿工做的。