让JavaScript在WebAssembly上加速运行！

　　大家好，很高兴又见面了，我是高级前端进阶，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发！
　　高级前端进阶让JavaScript在WebAssembly上疾速运行
　　与二十年前相比，如今JavaScript在浏览器中的运行速度要快好多倍。而这多亏了浏览器厂商们在此期间坚持不懈地加强性能优化。
　　而现在，我们又要开始在完全不同的运行环境中优化JavaScript的性能这些新环境中的游戏规则是截然不同的。而让JavaScript能够适应不同运行环境的，正是WebAssembly。
　　这里我们要明确一点如果你是在浏览器中运行JavaScript，那么直接部署JavaScript就行了。浏览器中的JavaScript引擎已经被精心调校过，可以很快速地运行装载进来的JavaScript程序。
　　但如果是在无服务器（Serverless）功能中运行JavaScript呢？又或者说，如果想要在iOS或游戏机这类不支持通常的即时编译的环境中运行JavaScript，又该如何把控性能？
　　在这些使用场景中，你会需要关注这新一轮的JavaScript优化。另外，若想要让Python、Ruby或者Lua等其他运行时语言在上述使用场景中提速，JavaScript优化也有参考价值。
　　但在开始探索如何在不同环境中进行优化前，我们需要了解一下其中的基本原理。原理是什么？
　　不论你在何时运行Javascript程序，JavaScript代码终归要以机器编码的形式执行。JavaScript引擎通过一系列技术来实现这一转换，例如各种解释器和JIT编译器。（详情请参见即时（JIT）编译器速成课。）
　　但如果你想要运行程序的平台没有JavaScript引擎怎么办？那你就需要把JavaScript引擎和程序代码一起部署。
　　为了能让JavaScript随处运行，我们把JavaScript引擎部署为一个WebAssembly模块，这样就能够跨越不同机器架构之间的差异。而且，借助WASI，跨操作系统也同样成为可能。
　　这意味着，整个JavaScript运行环境被集成进了WebAssembly实例中。部署了WebAssembly后，你只需把JavaScript代码喂进去就行了，WebAssembly实例会自行消化代码。
　　JavaScript引擎并不会直接在机器内存中运转，从二进制码到二进制码的垃圾回收对象，JavaScript引擎把这一切都放到Wasm模块的线性内存中。
　　对于JavaScript引擎，我们选用了SpiderMonkey，就是Firefox浏览器中用到的那个。SpiderMonkey是行业级别的JavaScript虚拟机（VM）之一，在浏览器领域里是久经沙场的老将。当你运行不可信代码，或者代码会处理不可信输入信息时，这种皮实耐用、安全性高的特性就显得尤为重要了。
　　SpiderMonkey还使用了一种叫做精确堆栈扫描的技术，它对我下面将要说到的部分优化点极其重要。SpiderMonkey还具有包容度极高的代码库，这一点也很重要，因为协作开发者们来自三个不同的组织Fastly、Mozilla和Igalia。
　　我刚刚描述的运行方式并没有显得具有什么颠覆性特征。几年前大家就已经开始这样用WebAssembly运行JavaScript了。
　　但问题在于，这样运行很慢。WebAssembly并不支持动态地生成新的机器编码，然后在纯Wasm代码里运行。这就意味着你无法使用即时编译。你只能使用解释器。
　　知道了有这种局限性，你可能会问：那为何还要说性能优化？
　　鉴于即时编译让浏览器能快速运行JavaScript（且鉴于在WebAssembly模块中不能进行即时编译），还想提速似乎是反直觉的。
　　但假如，即使不能用即时编译，我们还有没有办法能让JavaScript运行提速呢？
　　让我们通过几个案例来看看，如果WebAssembly可以快速运行JavaScript，将会产生多么大的效益。在iOS（以及其他JIT受限的环境）中运行JavaScript
　　在有些环境下，由于安全原因，无法使用即时编译，举例来说，无特殊权限的iOS应用、部分智能电视以及游戏机设备都属于此范畴。
　　在这些平台上，必须要使用解释器才行。但想在这些平台上运行的，都是那种运行周期长、代码量大的应用。正是这些条件让你不想用解释器，因为解释器会严重拖慢执行速度。
　　如果能让JavaScript在这样的环境中提速，那么开发者们就可以在不支持即时编译的平台使用JavaScript而无需顾虑性能了。让无服务器即刻冷启动
　　在另外一些场景中，即时编译不成问题，但启动时间却拖了后腿，比如在使用无服务器功能时。这就是冷启动延迟的问题，你可能已经有所耳闻。
　　即使用精简到极致的JavaScript环境，一个仅启动纯JavaScript引擎的隔离环境，最低延迟也有5毫秒左右，还没有把初始化应用的时间算进去。
　　倒是有一些办法可以把收到的请求的启动延迟隐藏起来。但随着QUIC这类提案在网络层中对连接时长的优化，想要隐藏延迟越来越困难。而当你链式执行多个无服务器功能等这类操作时，要隐藏延迟更是难上加难。
　　使用这些技术去隐藏延迟的平台页，常常会在多个请求间复用实例。某些情况下，这意味着在不同请求中都可以观察到全局状态，这就是拿安全当儿戏了。
　　正是由于这个冷启动问题，开发者们常常无法遵循最佳实践来开发。他们会在一次无服务器部署中，塞入大量功能。这就导致了另一个安全问题，一处暴雷，全盘完蛋。如果这次部署中的一部分破防了，那么攻击者就有了整个部署的访问权限。
　　但如果能把上述场景中JavaScript的启动时间降到足够低，那自然就无需再费尽心思去隐藏启动时间了，因为能在几微秒之间就启动一个实例。
　　如果能做到这种程度，就能为每个请求提供一个新实例，于是不会再有全局状态横穿多个请求。而且，由于这些实例足够轻量，开发者能够任意把代码拆分成粒度更细的片段，把每一段代码的故障范围压缩到最小。
　　这种实现还有另外一个安全方面的优点。除了实例能保持轻量、代码隔离粒度更优之外，Wasm引擎能提供的安全壁垒也更坚固了。
　　JavaScript引擎过去用来创建隔离的代码库庞大无比，包含着大量用来进行极其复杂的优化工作的底层代码，所以很容易产生Bug，从而使得攻击者跳出虚拟机、获取到虚拟机所在系统的访问权限。这就是为何像Chrome和Firefox这样的浏览器要竭尽全力确保网站运行在完全隔离的进程中。
　　相反的是，Wasm引擎需要的代码极少，因此便于检查，而且它们中有许多是用Rust这种内存无害语言写的。而由WebAssembly模块生成的原生二进制码，其内存隔离的安全性是可以验证的。
　　通过在Wasm引擎中运行JavaScript代码，构筑起了这座安全性更高的外部沙盒堡垒，以此作为另一道防线。
　　因此，在上述这些场景中，让JavaScript在Wasm引擎上运行得更快，是裨益良多的。那我们怎么来实现呢？要回答这个问题，需要弄清楚JavaScript引擎把时间都消磨在哪里了。JavaScript的两个耗时之处
　　可以粗略地把JavaScript引擎所做的工作拆分为两个部分：初始化和运行时。
　　把JavaScript看作是一个包工头。这位包工头被雇用来完成这样一份工作，即运行JavaScript代码，并得出结果。
　　初始化阶段
　　在这位包工头真正开始运作项目之前，它需要做一点预备工作。此初始化阶段包括了在执行之初所有那些只需运行一次的操作。应用初始化
　　不论是什么项目，合同工都需要了解一下客户的需求，然后配置要完成任务所需的资源。
　　例如，合同工浏览一遍项目概要以及其他支持文档，然后把它们转化成自己能处理的东西，比如搭建一个项目管理系统，把所有文档存储并整理起来。
　　在JavaScript引擎看来，这个任务更像是通读顶层源码并把各项功能解析为字节码、为声明的变量分配内存、给已经定义过的变量赋值。引擎初始化
　　在无服务器等特定场景中，还有另一个需要初始化的部分，发生在应用初始化之前。
　　那就是引擎初始化。引擎本身需要率先启动起来，内置函数需要添加到环境当中。可以把这个过程看作在开始工作之前要先把办公室布置好，组装桌椅之类的事。
　　这个过程也可能花费一定量的时间，也是导致冷启动成为无服务器使用场景的大问题的原因之一。运行时阶段
　　一旦初始化阶段结束，JavaScript引擎就能开始运行代码了。
　　把这部分工作的完成速度称为吞吐量（Throughput），能影响吞吐量的因素有很多。比如：功能使用哪种语言开发JavaScript引擎是否能预测代码行为使用哪种数据结构代码的运行周期是否足够长到能从JavaScript引擎的优化编译中获益
　　那么这就是JavaScript消耗时间的两个阶段。
　　那该如何让这两个阶段运行得更快呢？大幅压缩初始化耗时
　　先使用Wizer这个工具来加快初始化过程。稍后我会解释如何操作，但为了让心急的读者一睹为快，下面先给出运行一个非常简单的JavaScript应用时的加速情况。
　　当用Wizer运行这个小应用时，只消耗了0。36毫秒（等于360微秒）。这要比纯JavaScript的方式快了不止13倍。
　　启动能如此迅速，是因为借助了快照（Snapshot）。NickFitzgerald在WebAssembly峰会上关于Wizer的演讲中进行了更为详尽的解释。
　　那么其中的原理是什么？在部署代码之前，作为构建步骤的一部分，用JavaScript引擎运行JavaScript代码，直到初始化结束。
　　在此处，JavaScript引擎把所有的JavaScript代码解析成了字节码，并存储在了线性内存中。在这一阶段，引擎还会进行大量的内存分配和初始化工作。
　　由于线性内存的独立完备性非常强，当所有的数据值被存进来后，直接把这块内存绑定为Wasm模块的数据区块即可。
　　当JavaScript引擎模块被实例化后，它就能访问数据区块中的所有数据了。当引擎需要使用这块内存时，它可以复制所需的区块（或者内存页）到自己的线性内存中去。这样，JavaScript引擎在启动时就无需再做配置工作了。所有的预初始化的数据就都已经准备就绪、听凭差遣了。
　　眼下，把这个数据区块和JavaScript引擎绑在了一起。但在将来，一旦模块链接（Modulelinking）可用了，就能把数据区块装载为一个单独的模块了，也就能让JavaScript引擎被多个不同的JavaScript应用复用了。
　　这样就实现了真正干净清爽的解耦。
　　JavaScript引擎模块只包含引擎本身的代码。这意味着一经编译完成，这部分代码就可以高效率地被多个不同实例缓存和复用了。
　　另一方面，特定的应用模块不包含Wasm代码。它只含有线性内存，而线性内存只含有JavaScript代码字节码，以及初始化生成的JavaScript引擎状态数据。这让内存整理和分配十分便利。
　　就好像是包工头JavaScript引擎根本不需要再去布置办公室了。它直接可以拎包入住了。它的包里装下了整个办公室，所有器具一应俱全，全部都调校就绪，就等JavaScript引擎破土动工了。
　　而最酷的就是，这不是特地为JavaScript实现的只需要使用WebAssembly现有的属性即可。所以你也可以把这个办法用在Python、Ruby、Lua或其他运行时环境中。下一步：提升吞吐量
　　通过这种方式，可以让启动时长超级短了，那如何优化吞吐量呢？
　　对于某些情况来说，吞吐量其实不算差。如果你的JavaScript应用运行周期非常短，它怎么也轮不到即时编译来处理它的全程都在解释器中完成。在这种情况中，吞吐量就和在浏览器中一样了，在传统的JavaScript引擎初始化完成之前，程序就已经运行完了。
　　但是对于运行周期更长的JavaScript代码，即时编译用不了多久就得开始介入了。一旦发生这种情况，吞吐量的差异就开始变得悬殊了。
　　如上面所言，在纯WebAssembly环境中是不可能使用即时编译的。但事实上，可以把即时编译的一些想法应用到提前编译模型中。快速AOT编译JavaScript代码（无分析）
　　即时编译用到的一个优化技术是内联缓存（Inlinecaching）。通过内联缓存，即时编译创建一个存根链表，其中包含了机器编码的快捷路径，指向曾经运行过的JavaScript字节码的所有运行方式。（详情请参阅文章：即时编译器速成课）
　　之所以需要用链表，是因为JavaScript是动态类型语言。每当一行代码变换了不同的类型，就需要生成一个新的存根，添加到链表中。但如果之前就处理过这个类型，那就可以直接使用已经生成好的存根。
　　由于内联缓存（IC）在即时编译中比较常用，人们会认为它们是非常动态化的，并且专用于特定程序。但实际上，它们也可以用于AOT场景。
　　即使还没有看到JavaScript代码，也对要生成的IC存根比较熟悉了。这是因为JavaScript中有一些模式是经常被使用到的。
　　访问对象属性就是一个有力佐证。访问对象属性在JavaScript中非常常见，而使用IC存根就能为这个操作提速。对于那些有确定形状或者隐藏类（即属性的存储位置相对固定）的对象来说，当你读取这类对象的某个属性，该属性总在同样的偏移位置（Offset）上。
　　按照传统，即时编译中的这种IC存根会硬编码为两种值：一个是指向形状的指针，一个是属性的偏移量。而这所需的信息，是提前预知不到的。但能做的是把IC存根参数化。可以把形状和属性偏移量看作是传到存根里的变量。
　　这样，就能创建出一个单独的存根，它从内存中加载值，然后可以到处使用这个存根。可以把属于常见模式的所有存根合成一个AOT编译模块，不去关心JavaScript代码的具体功能细节。即使在浏览器设置中，这种IC共享也是有益处的，因为这让JavaScript引擎生成更少的机器编码，提升启动速度，优化本地指令缓存。
　　对于我们的使用场景来说，IC共享尤其重要。它意味着可以把属于常见模式的所有存根合成一个AOT编译模块，不去关心JavaScript代码的具体实现细节。
　　我们发现，仅需几KB的IC存根，就能覆盖全部JavaScript代码中的绝大部分。例如，只需2KB的IC存根，就足以覆盖GoogleOctane基准测试中95的JavaScript代码。从初步测试结果来看，通常的网页浏览场景似乎都能保持这个比率。
　　因此，使用这种优化手段，我们应该能够达到早期即时编译的吞吐量水平。一旦我们做到这个程度，我们就将加入更细粒度的优化，进一步打磨性能，正如各个浏览器厂商的JavaScript引擎开发团队在早期即时编译中所做的那样。下一步：或许该加一点分析？
　　以上是能提前做的，无需知道程序是做什么的，也无需知道它都使用了什么类型的数据。但要是能像即时编译一样访问到分析数据呢？那就可以全面优化代码了。
　　但这会引出一个问题，开发者分析起自己的代码来往往十分困难。要想提取出有代表性的代码样本，实非易事。因此没法确定是否能得到优质的分析数据。
　　如果能找合适的工具来进行分析，那么还是有可能让JavaScript代码运行得像如今的即时编译一样快速（连热身的时间都不需要！）的。如今该如何上手？
　　这种新的方式让我们激动不已，期盼着能更上一层楼。也很激动地看到，其他动态类型语言可以用这种方式拥抱WebAssembly了。
　　因此，下面是有几种上手的方式，如果有任何问题，可以在Zulip中提问。对于其他想支持JavaScript的平台
　　要想在自己的平台运行JavaScript，你需要嵌入一个支持WASI的WebAssembly引擎，比如Wasmtime。
　　然后需要JavaScript引擎。在这一步里，我们为Mozilla的构建系统添加了对编译SpiderMonkey到WASI的完全支持。Mozilla将把SpiderMonkey的WASI构建添加到用于构建和测试Firefox的CI设置中。这让WASI成为了SpiderMonkey的线上质量目标，确保了WASI构建能够一直保持运转。这意味着可以如文中所讲的那样使用SpiderMonkey。
　　最后，需要让用户提供预先初始化的JavaScript代码。为了能助你一臂之力，我们还开源了Wizer，可以集成到构建工具中，产出针对特定应用的WebAssembly模块，以适用于JavaScript引擎模块所用的预先初始化内存。对于其他想要使用这种方法的语言
　　如果是Python、Ruby、Lua等语言的使用者，可以针对该语言构建出一个自己的版本。
　　首先，需要把运行时编译成WebAssembly，使用WASI作为系统调用，可参考我们对SpiderMonkey的处理。然后，可以按照上文所说，把Wizer集成到构建工具中，生成内存快照，这样就能用快照来加速启动。参考资料原文链接：https：bytecodealliance。orgarticlesmakingjavascriptrunfastonwebassembly
　　原文作者：LinClark
　　中文参考翻译：https：juejin。cnpost6981685894470172679