WebAssembly GC：高性能 Web 应用的新前沿

WebAssembly (Wasm) 的到来伴随着一个宏伟的承诺：为 Web 带来近乎原生的性能，为众多编程语言创建一个通用的编译目标。对于使用 C++、C 和 Rust 等系统级语言的开发者来说，这个承诺相对较快地得以实现。这些语言提供了对内存的精细控制，能够清晰地映射到 Wasm 简洁而强大的线性内存模型上。然而，对于全球开发者社区中的一大部分人——那些使用 Java、C#、Kotlin、Go 和 Dart 等高级托管语言的开发者——通往 WebAssembly 的道路却充满了挑战。

核心问题一直是内存管理。这些语言依赖垃圾回收器 (GC) 来自动回收不再使用的内存，将开发者从手动分配和释放的复杂性中解放出来。将这种模型与 Wasm 的隔离线性内存集成，在过去一直需要繁琐的变通方案，导致了臃肿的二进制文件、性能瓶颈和复杂的“胶水代码”。

WebAssembly GC (WasmGC) 应运而生。这套变革性的提案不仅仅是一次增量更新；它是一次范式转变，从根本上重新定义了托管语言在 Web 上的运作方式。WasmGC 直接在 Wasm 标准中引入了一个一流的高性能垃圾回收系统，使得托管语言与 Web 平台之间能够实现无缝、高效和直接的集成。在这份全面的指南中，我们将探讨 WasmGC 是什么，它解决了哪些问题，它的工作原理，以及为什么它代表着一类新型强大、复杂 Web 应用的未来。

传统 WebAssembly 中的内存挑战

要充分理解 WasmGC 的重要性，我们必须首先了解它所解决的局限性。最初的 WebAssembly MVP (最小可行产品) 规范拥有一个极其简单的内存模型：一个被称为线性内存的、巨大的、连续且隔离的内存块。

可以把它想象成一个巨大的字节数组，Wasm 模块可以随意地对其进行读写。JavaScript 宿主环境也可以访问这块内存，但只能通过读写数据块的方式。这种模型速度极快且安全，因为 Wasm 模块被沙箱化在自己的内存空间内。它非常适合像 C++ 和 Rust 这样的语言，这些语言的设计理念就是通过指针（在 Wasm 中表现为线性内存数组的整数偏移量）来管理内存。

“胶水代码”的代价

当你想在 JavaScript 和 Wasm 之间传递复杂的数据结构时，问题就出现了。由于 Wasm 的线性内存只理解数字（整数和浮点数），你不能直接将一个 JavaScript 对象传递给 Wasm 函数。相反，你必须执行一个成本高昂的转换过程：

• 序列化： JavaScript 对象会被转换成 Wasm 能理解的格式，通常是像 JSON 这样的字节流或像 Protocol Buffers 这样的二进制格式。
• 内存复制： 这个序列化后的数据随后会被复制到 Wasm 模块的线性内存中。
• Wasm 处理： Wasm 模块会接收一个指向数据在线性内存中位置的指针（一个整数偏移量），将其反序列化回自己的内部数据结构，然后进行处理。
• 反向过程： 为了返回一个复杂的结果，整个过程必须反向再来一遍。

这整个流程都由“胶水代码”管理，通常由像 `wasm-bindgen` for Rust 或 Emscripten for C++ 等工具自动生成。虽然这些工具是工程上的奇迹，但它们无法消除持续的序列化、反序列化和内存复制所带来的固有开销。这种通常被称为“JS/Wasm 边界成本”的开销，对于需要频繁与宿主环境交互的应用来说，可能会抵消掉使用 Wasm 所带来的大部分性能优势。

自带 GC 的负担

对于托管语言来说，问题甚至更为深远。你如何在一个没有垃圾回收器的环境中运行一个需要垃圾回收器的语言？主要的解决方案是将该语言的整个运行时，包括它自己的垃圾回收器，都编译到 Wasm 模块本身。然后，这个 GC 会管理它自己的堆，而这个堆只是 Wasm 线性内存中一个大的分配区域。

这种方法有几个主要的缺点：

• 巨大的二进制文件体积： 捆绑一个完整的 GC 和语言运行时会给最终的 `.wasm` 文件增加几兆字节的大小。对于初始加载时间至关重要的 Web 应用来说，这通常是不可接受的。
• 性能问题： 捆绑的 GC 对宿主环境（即浏览器）的 GC 一无所知。这两个系统独立运行，可能导致效率低下。浏览器的 JavaScript GC 是一个经过数十年磨砺、高度优化、分代执行和并发的技术。一个编译到 Wasm 的自定义 GC 很难与这种复杂程度相媲美。
• 内存泄漏： 它创造了一种复杂的内存管理情景，浏览器的 GC 管理 JavaScript 对象，而 Wasm 模块的 GC 管理其内部对象。要在两者之间建立桥梁而不泄漏内存是出了名的困难。

WebAssembly GC 登场：一次范式转变

WebAssembly GC 通过扩展核心 Wasm 标准、增加管理内存的新功能来正面解决这些挑战。WasmGC 不再强迫 Wasm 模块在线性内存内管理一切，而是允许它们直接参与宿主的垃圾回收生态系统。

该提案引入了两个核心概念：引用类型和托管数据结构（结构体和数组）。

引用类型：通往宿主的桥梁

引用类型允许 Wasm 模块持有一个对宿主管理对象的直接、不透明的引用。其中最重要的是 `externref`（外部引用）。一个 `externref` 本质上是一个指向 JavaScript 对象（或任何其他宿主对象，如 DOM 节点、Web API 等）的安全“句柄”。

通过 `externref`，你可以通过引用的方式将一个 JavaScript 对象传入 Wasm 函数。Wasm 模块不知道该对象的内部结构，但它可以持有该引用，存储它，并将其传回给 JavaScript 或其他宿主 API。这在许多互操作场景中完全消除了序列化的需要。这就好比是邮寄一份详细的汽车蓝图（序列化）与直接递交车钥匙（引用）之间的区别。

结构体和数组：统一堆上的托管数据

虽然 `externref` 对宿主互操作性具有革命性意义，但 WasmGC 的第二部分对于语言实现来说更为强大。WasmGC 直接在 WebAssembly 中定义了新的高级类型构造：`struct`（命名字段的集合）和 `array`（元素的序列）。

至关重要的是，这些结构体和数组的实例并不会分配在 Wasm 模块的线性内存中。相反，它们被分配在一个由宿主环境（浏览器的 V8、SpiderMonkey 或 JavaScriptCore 引擎）管理的、共享的、垃圾回收的堆上。

这就是 WasmGC 的核心创新。Wasm 模块现在可以创建宿主 GC 能原生理解的复杂结构化数据。其结果是一个统一的堆，在这个堆上，JavaScript 对象和 Wasm 对象可以共存并无缝地相互引用。

WebAssembly GC 工作原理：深入探讨

让我们来剖析这个新模型的机制。当像 Kotlin 或 Dart 这样的语言被编译到 WasmGC 时，它会以一组新的 Wasm 内存管理指令为目标。

• 分配： 编译器不再调用 `malloc` 来预留线性内存块，而是发出像 `struct.new` 或 `array.new` 这样的指令。Wasm 引擎会拦截这些指令，并在 GC 堆上执行分配。
• 字段访问： 像 `struct.get` 和 `struct.set` 这样的指令被用来访问这些托管对象的字段。引擎会安全高效地处理内存访问。
• 垃圾回收： Wasm 模块不需要自己的 GC。当宿主 GC 运行时，它可以看到整个对象引用图，无论这些引用是源自 JavaScript 还是 Wasm。如果一个由 Wasm 分配的对象不再被 Wasm 模块或 JavaScript 宿主引用，宿主 GC 将自动回收其内存。

双堆合一

旧模型强制实行严格的分离：JS 堆和 Wasm 线性内存堆。有了 WasmGC，这堵墙被推倒了。一个 JavaScript 对象可以持有一个对 Wasm 结构体的引用，而那个 Wasm 结构体也可以持有一个对另一个 JavaScript 对象的引用。宿主的垃圾回收器可以遍历这整个图，为整个应用程序提供高效、统一的内存管理。

正是这种深度集成，使得各种语言能够摆脱它们自定义的运行时和 GC。它们现在可以依赖每个现代 Web 浏览器中已经存在的强大、高度优化的 GC。

WasmGC 为全球开发者带来的切实好处

WasmGC 的理论优势转化为开发者和全球最终用户实实在在的、改变游戏规则的好处。

1. 显著减小的二进制文件体积

这是最立竿见影的好处。通过消除捆绑语言内存管理运行时和 GC 的需要，Wasm 模块变得小得多。来自 Google 和 JetBrains 团队的早期实验已经显示出惊人的结果：

• 一个简单的 Kotlin/Wasm 'Hello, World' 应用，之前在捆绑自己的运行时后体积达数兆字节 (MB)，而在使用 WasmGC 后缩小到仅几百千字节 (KB)。
• 一个 Flutter (Dart) Web 应用在迁移到基于 WasmGC 的编译器后，其编译后的代码大小减少了 30% 以上。

对于全球用户而言，网络速度可能千差万别，更小的下载体积意味着更快的应用加载时间、更低的数据成本和更好的用户体验。

2. 大幅提升的性能

性能提升来自多个方面：

• 更快的启动速度： 更小的二进制文件不仅下载更快，浏览器引擎解析、编译和实例化的速度也更快。
• 零成本互操作： JS/Wasm 边界上昂贵的序列化和内存复制步骤在很大程度上被消除了。在两个领域之间传递对象变得像传递指针一样廉价。这对于频繁与浏览器 API 或 JS 库通信的应用来说是一个巨大的胜利。
• 高效、成熟的 GC： 浏览器 GC 引擎是工程上的杰作。它们是分代的、增量的，并且通常是并发的，这意味着它们可以在对应用程序主线程影响最小的情况下完成工作，防止卡顿和“掉帧”。WasmGC 应用可以免费利用这项世界级的技术。

3. 更简化、更强大的开发体验

WasmGC 使得从托管语言面向 Web 开发变得自然且顺畅。

• 更少的胶水代码： 开发者花费更少的时间编写和调试用于在 Wasm 边界来回传递数据的复杂互操作代码。
• 直接操作 DOM： 通过 `externref`，Wasm 模块现在可以直接持有对 DOM 元素的引用。这为用 C# 或 Kotlin 等语言编写的高性能 UI 框架像原生 JavaScript 框架一样高效地操作 DOM 打开了大门。
• 更容易的代码移植： 将现有的用 Java、C# 或 Go 编写的桌面或服务器端代码库重新编译以用于 Web 变得更加直接，因为核心的内存管理模型保持一致。

实际影响与未来展望

WasmGC 不再是遥远的梦想；它已成为现实。截至 2023 年末，它已在 Google Chrome (V8 引擎) 和 Mozilla Firefox (SpiderMonkey) 中默认启用。Apple 的 Safari (JavaScriptCore) 的实现也在进行中。主要浏览器供应商的广泛支持表明 WasmGC 是未来的方向。

语言和框架的采用

生态系统正在迅速拥抱这项新功能：

• Kotlin/Wasm： JetBrains 一直是主要的支持者，Kotlin 是首批对 WasmGC 目标提供成熟、生产就绪支持的语言之一。
• Dart & Flutter： Google 的 Flutter 团队正积极使用 WasmGC 将高性能的 Flutter 应用带到 Web，摆脱了他们之前基于 JavaScript 的编译策略。
• Java & TeaVM： TeaVM 项目是一个 Java 字节码的提前编译器，它支持 WasmGC 目标，使 Java 应用能够在浏览器中高效运行。
• C# & Blazor： 虽然 Blazor 传统上使用编译到 Wasm 的 .NET 运行时（带有其自己捆绑的 GC），但该团队正在积极探索 WasmGC，以期显著提高性能并减小负载大小。
• Go： 官方的 Go 编译器正在添加一个基于 WasmGC 的目标 (`-target=wasip1/wasm-gc`)。

对 C++ 和 Rust 开发者的重要说明： WasmGC 是一项附加功能。它不会取代或弃用线性内存。执行自有内存管理的语言可以并且将继续像以前一样使用线性内存。WasmGC 只是为那些能从中受益的语言提供了一个新的、可选的工具。这两种模型甚至可以在同一个应用中共存。

概念性示例：WasmGC 前后对比

为了让差异更具体，让我们看一个将用户数据对象从 JavaScript 传递到 Wasm 的概念性工作流程。

WasmGC 之前 (例如，使用 wasm-bindgen 的 Rust)

JavaScript 端：

            
const user = { id: 101, name: "Alice", isActive: true };
// 1. Serialize the object
const userJson = JSON.stringify(user);

// 2. Encode to UTF-8 and write to Wasm memory
const wasmMemoryBuffer = new Uint8Array(wasmModule.instance.exports.memory.buffer);
const pointer = wasmModule.instance.exports.allocate_memory(userJson.length + 1);
// ... code to write string to wasmMemoryBuffer at 'pointer' ...

// 3. Call Wasm function with pointer and length
const resultPointer = wasmModule.instance.exports.process_user(pointer, userJson.length);
// ... code to read result string from Wasm memory ...

            

              
                Copy
              
            
          

这涉及到多个步骤、数据转换以及在两端都需进行的小心翼翼的内存管理。

WasmGC 之后 (例如，Kotlin/Wasm)

JavaScript 端：

            
const user = { id: 101, name: "Alice", isActive: true };

// 1. Simply call the exported Wasm function and pass the object
const result = wasmModule.instance.exports.process_user(user);

console.log(`Received processed name: ${result.name}`);

            

              
                Copy
              
            
          

区别是显而易见的。互操作边界的复杂性消失了。开发者可以在 JavaScript 和 Wasm 编译的语言中自然地处理对象，而 Wasm 引擎会高效且透明地处理通信。

与组件模型的关联

WasmGC 也是实现 WebAssembly 更宏大愿景——组件模型——的关键基石。组件模型旨在创造一个未来，在这个未来里，用任何语言编写的软件组件都可以通过丰富的高级接口无缝通信，而不仅仅是简单的数字。为了实现这一点，你需要一种标准化的方式来描述和传递复杂数据类型——如字符串、列表和记录——在组件之间。WasmGC 提供了基础的内存管理技术，使得处理这些高级类型变得高效和可能。

结论：未来是托管与高性能的结合

WebAssembly GC 不仅仅是一项技术特性；它是一项解锁性技术。它打破了阻碍庞大的托管语言生态系统及其开发者全面参与 WebAssembly 革命的主要障碍。通过将高级语言与浏览器原生、高度优化的垃圾回收器集成，WasmGC 实现了一个强大的新承诺：你不再需要在高级生产力与 Web 上的高性能之间做出选择。

其影响将是深远的。我们将看到新一波复杂的、数据密集型的高性能 Web 应用——从创意工具和数据可视化到功能齐全的企业软件——使用以前在浏览器中不切实际的语言和框架构建。它让 Web 性能大众化，让全球的开发者能够利用他们在 Java、C# 和 Kotlin 等语言中的现有技能来构建下一代 Web 体验。

在托管语言的便利性与 Wasm 的性能之间进行选择的时代已经结束。感谢 WasmGC，Web 开发的未来既是托管的，也是极其快速的。