对于最近 Chrome V8 JavaScript 引擎中引入的后台编译,这篇文章探讨了其中的一些细节。
在 Google 浏览器 Chrome 的最新版本(Beta v.33)中, JavaScript V8 引擎方面具有一项重要的变化:引入了使用后台线程进行优化编译处理的能力,从而让主线程能够继续对用户保持响应并获得性能提升。据从事此工作的 Google 工程师 Yang Guo 透露, V8 将完成两种类型的编译:
为了减少在编译方面消耗的整体时间,V8 将 JavaScript 函数的编译推迟,直到它们首次执行前才会进行此工作。这一编译阶段非常迅速,但是并不以优化代码为重点,而是聚焦于快速完成编译。在 V8 中,频繁运行的代码片段将得到第二次编译——由专用的优化编译器(Crankshaft)完成。在第二遍编译中,使用了许多高级优化技术,这意味着第二遍编译将比第一遍消耗更多的时间,但是其产出的代码运行起来更快。
Guo 介绍的,在使用 Nexus5 运行 Octane 2.0 基准测试套件中的 Mandreel 测试时,我们可以看到,通过由独立线程负责优化编译,应用不仅仅更加具有响应性,而且运行速度提高了 27%。
InfoQ 对 Chrome V.33 进行了一些测试,记录了分别使用(–js-flags="–concurrent-recompilation")或禁止(–js-flags="–no-concurrent-recompilation")并行重编译时的运行结果。对于 Octane 2.0 基准测试,我们观测到了以下性能提升(对连续 5 次测试的结果进行平均,且每次运行时都重新启动了浏览器):
测试
提升
Octane 2.0 (全部 17 项测试)
7.12%
Mandreel
18%
Box2DWeb
32%
zlib
11%
从上表可以看到,对于 Octane 基准测试套件整体的测试来说,性能提升了 7% 升;而在 2D 和 3D 引擎方面,提升则更为显著。 以确保我们知道他并不是为 Google 说好话(当时他尚未加入此团队),我们询问 Guo,为何在 2010 年 12 月发布 Crankshaft 时没有引入优化编译。Guo 表示,最新版本中增加的这些改进,都是源自实际的需求:
在设计 Crankshaft 的时候,延迟并不是很大的问题。考虑到当时 JavaScript 代码的大小,编译时间尚未成为显著的问题,因此低延迟既不算是问题,也不是 CrankShaft 的设计目标。在我看来,在那个时候引入并发,将令刚刚起步的优化编译器的设计,变得毫无必要的复杂;这将引入不成熟的优化,却不能带来任何即刻的好处。
显然,在最近几年中这一情况发生了变化。如果查看最新版本的 Octane 基准测试套件,我们将发现到某些代码的大小已经超过了 1MB。这反映出,现实世界里的一些应用正在推动 JavaScript 引擎逼近其极限。Mandreel 基准测试包含了 4.8MB 的压缩后的代码。为了让这一概念更直观,我们可以以 PhotoShop 1.0 版本为例,其源代码在解压缩后也只有 4.4MB 而已。“搅动”这个量级的代码将需要很多时间,特别是在执行例如动画渲染等工作(期望能够在一张眼间完成)时,这将成为显著的问题。
Guo 没有试图面面俱到地介绍后台编译,而是告诉我们,在 V8 中实现这一特性的过程中,他们所面对的一些挑战:
- 每位计算机科学家都会告诉我们,搞定多线程并不是件容易的事情;难以保证测试的良好覆盖;并发固有的不确定性行为,使 Bug 的重现变得困难,甚至可以说几乎不可能。拥有一套良好的测试用例,使用由断言包含的常量、模糊测试,并且最后很重要的是使用 Canary 测试覆盖。这些将帮助我们树立起对结果正确与否的信心。顺便说一下,在这里我要向 ThreadSanitizer 团队致敬。
- 当编译阻塞执行的时候,我们能够确信在编译前后,JavaScript 堆及以及其中全部对象的状态将保持一致。然而,面对并行编译,该假设不再成立。这将带来如下影响:
-V8 拥有一套负责重新部署的 GC,这意味着任何时候一旦 GC 发挥作用,对象们将被迁移。因此指向这些对象的引用必须得到更新。在执行编译任务的同时,很有可能发生这种情况。而如果编译任务所持有的对象,其引用未能得到更新,那么编译过程最终将内存访问失效的问题。
- 在进行并行编译时,执行仍将继续进行。这意味着虚拟机的状态、对象的内容以及布局将能够恣意改变。基于编译任务开始时的情况所做出的假设条件,或许在编译结束时将不再成立。甚至也许编译结束时产出的代码将不再有效。运行这些代码会引发 Bug 和崩溃。这一现象必须得到妥善处理。
- 实际上,允许后台线程在任何时候访问堆,会很容易引发竞争条件。我们通过提前为编译工作收集所有必要的信息来避免这一情况。
- 要想找到合适的时机启动后台线程中的编译任务,是一件非常棘手的事情:没有什么方法,能够准确预测是否值得在优化某个代码片段上投入时间,以及是否应该更早完成优化以从中受益。制定启发式解决方案来应对这个问题,则更加困难——必须进行许多精细的调整,而这项工作仍处于进行之中。
- 随着源代码片段即将经历的相互关联的状态——例如延迟解析,使用快速编译器进行第一遍编译,接下来由优化编译器进行优化,随后或许会进行“去优化”(deoptimized,如果在编译启动时所做的假设已经不在成立)等等——它的生命周期变得非常复杂。而由于并行编译的出现,这个生命周期中还增加了一些新的状态。对所有状态保持跟踪,确保在状态之间高效转移而不出 Bug,是件很复杂的工作。未经预料的极端情况可能会引发问题。
Guo 表示,“V8 正处于积极发展的阶段,并且正在稳步改进”。例如,大家可以在由 Dart 维护的实时性能图表格中看到,V8 的表现在 2 月 11 日运行的 DeltaBlue 基准测试出现了 30% 的飞跃——这一结果来自编译器本身的优化,而不是后台编译。
评论