WebAssembly

type

status

date

slug

summary

JavaScript的限制

字节码进入翻译器后，将字节码一行一行地翻译成效率十分高的Machine Code.

在项目运行的过程中，引擎会记住执行次数较多的function，引擎将其代码编译成Machine Code后打包送到顶部的Just-In-Time(JIT) Compiler，下次再执行这个function，就会直接执行编译好的Machine Code。但是由于JavaScript的动态变量，上一秒可能是Array，下一秒就变成了Object。那么上一次引擎所做的优化，就失去了作用，此时又要再一次进行编译。

由于JS缺失静态变量，JIT很难重用编译好的Machine Code，从而性能被限制

console.log(sum(1,2,3))

console.log(sum('1',2,3))

JIT 在遇到第一个 sum 时会编译成整数相加的机器码；但是在碰到第二个 sum 调用时，不得不重新编译一遍。这样一来，JIT 带来的效率提升便被抵消了。

什么是WebAssembly

WebAssembly 不是一种语言，而是一种编译目标

WebAssembly 由 asm.js 而来，asm.js 也是一种编译目标，但是 asm.js 仍然需要经过Parser 和 ByteCode Compiler，而WebAssembly不用经过这两步。

WebAssembly是经过编译器编译之后的代码，在语法上完全脱离JavaScript，同时具有沙盒化的执行环境。

云原生：在服务端，Wasm 轻量级容器

WebAssembly 可以允许任何语言编译到它制定的 AST tree，相当于使用其他高级语言写的代码可以直接在网页上运行

这也使得很多应用能直接移植到Web上来，几乎不需要重构

Wasm省去了比较耗时的解析和编译的过程，是直接生成的二进制可执行机器码供浏览器进行执行。

与eBPF关联

目前大多数在浏览器外运行的 Wasm 轻量级容器需要使用 WASI（WebAssembly 系统接口）与其 host 操作系统交互，相对于传统的容器中可以使用几乎所有的系统调用，目前 WASI 所能提供的系统资源非常有限，目前仅仅在文件系统、socket 网络连接等方面提供了一些基本的支持，对于操作系统底层资源的访问、控制和管理能力仍然存在大量空白。这也使得大多数的 Wasm 轻量级容器在实际应用中还是主要集中于纯粹的计算密集型应用，而在网络、安全等方面，还是需要依赖于传统的容器技术。

eBPF 的兴起使得云原生开发人员能够构建安全的网络、和多种可观测性组件，并且提供强大的内核态可编程交互能力。

通过eBPF，能够让 Wasm 虚拟机或者 Wasm 轻量级容器中的应用，有能力下沉和拓展到内核态，获取内核态和用户态的几乎所有数据，在网络、安全等多个方面实现对整个操作系统层面的可编程控制，从而极大的拓展 WebAssembly 生态在非浏览器端的应用场景。

类似于在浏览器中运行的 Wasm 程序，它们通过 JavaScript 引擎接口访问浏览器提供的各种系统资源，那服务端的方案就是借助 eBPF 虚拟机访问操作系统的各类资源。

让 Wasm 应用在沙箱中实现和用户态中 eBPF 应用一样的编程模型和执行逻辑。