新版Firefox让JavaScript和WebAssembly之间的函式呼叫更顺畅

Firefox中JavaScript和WebAssembly间函式呼叫更加顺畅了，Mozilla在最新版本Firefox Nightly中最佳化了JavaScript到WebAssembly，以及从WebAssembly到JavaScript两个方向的呼叫，主要的手段有两个，减少簿记以及消除中介。

Mozilla对Firefox执行WebAssembly的效能，持续做出改进，在Firefox 58中加入了串流编译以及分层编译技术，让电脑版的Firefox每秒可以编译30到60MB的WebAssembly程式码，也就是说程式码编译的速度将能快过网络下载速度，使得程式码下载结束时，也能几乎同时完成应用程序编译工作。

而现在把效能改善的目标，转向函式呼叫上，Mozilla提到，他们一开始的工作是让JavaScript和WebAssembly可以相互合作，而这件事并不难，只是这两种语言的函式呼叫效率不高，甚至慢的出名。Mozilla在Firefox Nightly上，最佳化了从JavaScript到WebAssembly，和从WebAssembly到JavaScript两个方向的函式呼叫，同时也加速了WebAssembly呼叫浏览器内建函数的呼叫。

最佳化的工作可以归结为两个主要做法，除了减少簿记 ，以减少不必要的组织堆叠框（Stack Frame）工作，还移除中介，以最直接的途径操作函式。每种浏览器都有自己的JavaScript引擎，之前只要处理JavaScript，现在还多了WebAssembly，即便只处理JavaScript，引擎都必须处理两种不同的语言字节码和机器码。

部分JavaScript程式码会进到直译器中，被转成字节码，这比起JavaScript更接近机器码，执行的速度相对来说比较快，但又不如机器码。而部分被大量呼叫的函式则会经由即时编译器（JIT）直接转换为机器码，这过程不需要经过直译器。

这两种语言就像是两块不同的大陆，引擎要执行不同的语言就像是在大陆之间跳跃，但跳跃时需要记录一些必要讯息，而为了组织这个工作，引擎需要一个类似文件夹概念的地方，存放跳跃旅行的堆叠框，随着累积文件夹数量会越来越多，而每切换到不同的大陆，引擎就会启用一个不必要的文件夹，新增文件夹必会经C++进行弹跳床（Trampoline），这会明显的增加执行成本。

Mozilla让经过JIT的JavaScript和WebAssembly的程式码，都使用相同的文件夹来修正这个问题，就像是把两块大陆合并在一起，不再需要在大陆间跳跃，因而让WebAssembly到JavaScript的呼叫，几乎和JavaScript呼叫JavaScript的函式一样快。

另外，除了WebAssembly到JavaScript呼叫需要提高效率外，反向更是需要加速。即便是JIT-ed JavaScript已经和WebAssembly使用相同的语言，但是语言的处理习惯仍然不同，像是JavaScript会使用Boxing来处理动态类型，但WebAssembly是静态型别，因此当引擎从JavaScript获取经装箱（Boxing）的参数，并传递给WebAssembly函式时，WebAssembly会不知道如何使用。

因此引擎在将装箱参数传递给WebAssembly之前，需要经过拆箱手续，而这个动作也需要经C++弹跳床手续。进入中介的过程需要极大的成本，特别是处理这些并不复杂的工作，因此Mozilla的策略是消除这个中间人，来加速整个过程。Firefox采用C++执行的进入存根（Entry Stub ）代码，使其可以从JIT程式码直接进行呼叫，当引擎从JavaScript转到WebAssembly时，进入存根将能直接拆箱并将他们放置到正确的位置，而这种方式则消除了经C++弹跳床的程序。

这个方式就像是小抄一样，引擎使用小抄因此不再需要转至C++，相反的，还可以在JavaScript和WebAssembly呼叫的过程间将值拆箱。这让JavaScript呼叫WebAssembly函式的速度变快，甚至在许多情况下，快过JavaScript呼叫JavaScript函式。

而在WebAssembly呼叫浏览器内建函数时，同样会有C++弹跳床所造成的效能低落问题，Mozilla为这些内建函式建立快速路径，当引擎发现正在呼叫的函式属于内建函式，便会使用快速路径来处理呼叫，这些快速路径就像是在大陆间建造快速强桥梁一样。

这一系列的改进让JavaScript和WebAssembly之间的沟通更为有效率，也让WebAssembly呼叫内建函式更为快速，虽然目前只有Firefox获得这些改进，但使用者可以期待其他浏览器也会很快的跟进。