写点什么

在 V8 引擎中实现后台编译所需应对的挑战

  • 2014-02-18
  • 本文字数:2219 字

    阅读完需:约 7 分钟

对于最近 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% 的飞跃——这一结果来自编译器本身的优化,而不是后台编译。

查看英文原文: Challenges Performing Background Compilation in V8

2014-02-18 18:492151
用户头像

发布了 256 篇内容, 共 72.2 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

面对key数量多和区间查询低效问题:Hash索引趴窝,LSM树申请出场

华为云开发者联盟

数据库 数据 存储 Hash索引 LSM树

音视频行业不可或缺的功能-云端录制

anyRTC开发者

音视频 WebRTC 在线教育 直播 RTC

微服务容错时,这些技术你要立刻想到

华为云开发者联盟

微服务 线程 服务雪崩 断路器 服务降级

数据中台:建立在数据网络效应之上的赛道

奇点云

大数据 数据中台 云原生 数据

我们都很忙

Ian哥

28天写作

Soul 源码阅读 05|Http 长轮询同步数据分析

哼干嘛

Vue3 中 v-if 和 v-show 指令实现的原理 | 源码解读

五柳

源码分析 大前端 Vue3

CSS实现数据统计

德育处主任

大前端 CSS小技巧 28天写作 纯CSS

浪漫主义的消亡

石君

28天写作

如何养成一个好习惯

熊斌

读书笔记 28天写作

开发质量提升系列:用户体验

罗小龙

最佳实践 方法论 28天写作

个人隐私之老话重谈

张老蔫

28天写作

前端模拟假数据(json-server光速入门篇)

德育处主任

json 大前端 Node 28天写作 json-server

HTML5中的拖放功能

我是哪吒

html html5 程序员 面试 大前端

美国大选期间美股迎来大涨,舆情到底有何魔力?

星环科技

人工智能 大数据

架构师训练营知识点思维导图

晴空万里

架构师训练营第2期

机器学习应用设计阶段的 10 个陷阱和 11 个最佳实践

机器学习

《论雨伞道德》- 不要和自己的良心捉迷藏

石云升

读书笔记 28天写作 雨伞道德

年底跳槽之 如何找工作方向?

一笑

职业规划 28天写作

代码 or 指令,浅析ARM架构下的函数的调用过程

华为云开发者联盟

函数 任务栈 arm架构

AI、IoT、区块链、自主系统、下一代计算五大技术引领未来供应链发展

京东科技开发者

区块链 AI IoT 供应链

Volcano 监控设计解读,一看就懂

华为云开发者联盟

Kubernetes 云原生 监控 Volcano 计算

漫谈HTTP协议

架构精进之路

HTTP 七日更 28天写作

技术根儿扎得深,不怕“首都”狂风吹!

鲁米

操作系统

区块链作用之数字货币的影响

v16629866266

机器学习·笔记之:Cost Function - Intuition I

Nydia

GNUCash 5: 报表

lidaobing

GNUCash 28天写作

记录关于写作的两个小想法

JiangX

28天写作

淘宝网前期技术架构演进分析

Andy

工程师思维是什么?能吃吗?

Justin

工程师思维 架构设计 28天写作

你会读书吗?

xcbeyond

读书感悟 读书方式 28天写作

在V8引擎中实现后台编译所需应对的挑战_Google_Abel Avram_InfoQ精选文章