WebAssembly GC 提案：Wasm 与 JavaScript 之间共享堆对象指针的性能损耗分析

尊敬的各位同仁，下午好！

今天，我们将深入探讨一个在Web平台高性能计算领域至关重要的议题：WebAssembly GC 提案下，WebAssembly (Wasm) 与 JavaScript (JS) 之间共享堆对象指针所带来的性能损耗及其优化策略。随着WebAssembly GC提案的逐步落地，我们终于能够让Wasm模块直接管理和分配堆对象，这为C++、Java、Kotlin、C#等高级语言编译到Wasm提供了更自然的内存模型和更优的运行时表现。然而，当这些Wasm管理的堆对象需要与JavaScript环境进行交互时，跨语言边界的性能挑战也随之浮现。

本次讲座，我将以编程专家的视角，为大家剖析这些挑战的根源，并提供一系列实用的优化建议。我们将不仅仅停留在理论层面，更会结合代码示例，力求将复杂的技术细节以清晰、严谨且易于理解的方式呈现。

1. WebAssembly GC 提案概览：开启堆管理新篇章

在WebAssembly GC提案之前，Wasm模块主要通过线性内存（WebAssembly.Memory）来管理数据，而堆对象（如JavaScript对象）则需通过externref类型间接引用。这种模型对于需要复杂对象图的高级语言来说，往往需要自行实现垃圾回收器或引用计数，增加了编译目标语言的复杂度，也限制了性能。

WebAssembly GC提案的核心目标是为Wasm引入原生的结构体（struct）和数组（array）类型，并使它们能够被Wasm运行时本身的垃圾回收器管理。这意味着Wasm模块现在可以：

• 定义结构体和数组类型：类似于C语言的struct或Java的class，以及原生数组。
• 分配和访问这些对象：在Wasm中直接使用指令分配、读取和写入这些堆对象。
• 受益于Wasm运行时的GC：Wasm引擎将负责这些对象的生命周期管理，与宿主环境（浏览器）的JS GC协同工作。

核心类型扩展：

WebAssembly GC提案引入了一系列新的引用类型，它们共同构建了Wasm的GC对象系统：

• anyref：所有GC引用的顶层类型，包括Wasm GC对象和externref。
• eqref：支持相等性比较的GC引用。
• i31ref：表示一个31位整数或引用，常用于小整数的优化存储。
• structref：Wasm定义的结构体对象的引用。
• arrayref：Wasm定义的数组对象的引用。
• dataref：抽象类型，表示所有可数据化的引用，目前主要指structref和arrayref。
• stringref：字符串类型（通过stringref提案引入，与GC提案紧密相关）。

Wasm GC 对象定义示例：

让我们看一个简单的Wasm模块如何定义并使用结构体和数组：

;; 定义一个简单的Point结构体：包含两个i32字段 x 和 y
(type $point (struct (field $x i32) (field $y i32)))

;; 定义一个Color结构体：包含三个i8字段 r, g, b
(type $color (struct (field $r i8) (field $g i8) (field $b i8)))

;; 定义一个Point数组类型
(type $point_array (array (mut $point))) ;; 可变元素的Point数组

(module
  (type $point (struct (field $x i32) (field $y i32)))
  (type $color (struct (field $r i8) (field $g i8) (field $b i8)))
  (type $point_array (array (mut $point)))

  ;; 导出一个函数，用于创建并返回一个Point对象
  (func $create_point (param $x i32) (param $y i32) (result (ref $point))
    (struct.new $point (local.get $x) (local.get $y))
  )

  ;; 导出一个函数，用于获取Point对象的x字段
  (func $get_point_x (param $p (ref $point)) (result i32)
    (local.get $p)
    (struct.get $point $x)
  )

  ;; 导出一个函数，用于创建并返回一个Color对象
  (func $create_color (param $r i32) (param $g i32) (param $b i32) (result (ref $color))
    (struct.new $color (local.get $r) (local.get $g) (local.get $b))
  )

  ;; 导出一个函数，用于创建并返回一个Point数组
  (func $create_point_array (param $size i32) (result (ref $point_array))
    (local.get $size)
    (array.new_default $point_array) ;; 创建指定大小的数组，元素初始化为默认值 (null.ref)
  )

  ;; 导出一个函数，用于设置Point数组的某个元素
  (func $set_point_array_element (param $arr (ref $point_array)) (param $index i32) (param $p (ref $point))
    (local.get $arr)
    (local.get $index)
    (local.get $p)
    (array.set $point_array)
  )

  (export "createPoint" (func $create_point))
  (export "getPointX" (func $get_point_x))
  (export "createColor" (func $create_color))
  (export "createPointArray" (func $create_point_array))
  (export "setPointArrayElement" (func $set_point_array_element))
)

在JavaScript中加载和使用这个Wasm模块：

// Assume the above Wasm code is compiled to 'gc_objects.wasm'
async function runGcExample() {
    const response = await fetch('gc_objects.wasm');
    const bytes = await response.arrayBuffer();
    const { instance } = await WebAssembly.instantiate(bytes);
    const exports = instance.exports;

    // 创建一个Wasm Point对象
    const p1 = exports.createPoint(10, 20);
    console.log("Wasm Point p1:", p1); // p1现在是一个Wasm GC对象，在JS中表现为一个HostRef对象
    console.log("p1.x (via JS property access):", p1.x); // Wasm GC对象在JS中会自动暴露字段为属性
    console.log("p1.y (via JS property access):", p1.y);

    // 获取x字段（通过Wasm函数）
    const x = exports.getPointX(p1);
    console.log("p1.x (via Wasm function):", x);

    // 创建一个Wasm Color对象
    const c1 = exports.createColor(255, 0, 128);
    console.log("Wasm Color c1:", c1);
    console.log("c1.r:", c1.r);
    console.log("c1.g:", c1.g);
    console.log("c1.b:", c1.b);

    // 创建Wasm Point数组
    const pointArr = exports.createPointArray(3);
    console.log("Wasm Point Array:", pointArr);
    console.log("pointArr[0] before set:", pointArr[0]); // 初始为null或undefined

    const p2 = exports.createPoint(30, 40);
    exports.setPointArrayElement(pointArr, 0, p2);
    console.log("pointArr[0] after set:", pointArr[0]);
    console.log("pointArr[0].x:", pointArr[0].x);
}

runGcExample();

在这个例子中，p1、c1、pointArr在JavaScript中表现为特殊的HostRef对象。它们是Wasm GC对象的代理或包装。JS可以像访问普通JS对象一样访问它们的字段和元素，而底层数据则由Wasm GC管理。正是这种看似无缝的交互，隐藏了性能损耗的玄机。

2. JavaScript 引擎的内部对象表示与优化

要理解Wasm GC对象与JS交互的性能瓶颈，我们首先需要回顾JavaScript引擎（如V8、SpiderMonkey、JavaScriptCore）是如何优化JS对象的。

JavaScript作为一种动态类型语言，其对象的结构在运行时可以随时改变。为了在保证灵活性的同时实现高性能，JS引擎采用了许多复杂的优化技术：

• 隐藏类（Hidden Classes / Shapes）：当JS对象被创建时，引擎会为其分配一个“隐藏类”或“形状”（Shape/Map）。这个隐藏类描述了对象的属性布局（属性名、偏移量、类型等）。当新的属性被添加或删除时，引擎会创建或查找一个新的隐藏类。通过隐藏类，属性访问可以被优化为简单的偏移量查找，避免了昂贵的哈希表查找。

  // 假设对象首次创建时
  let obj = { x: 10 }; // V8会为obj创建一个隐藏类HC1，记录x的偏移量
  obj.y = 20;          // V8会为obj创建一个新的隐藏类HC2，记录x和y的偏移量，并更新obj的隐藏类

  如果一个函数总是接收相同隐藏类的对象，JIT编译器可以生成高度优化的机器码（单态性，Monomorphism）。

• JIT 编译（Just-In-Time Compilation）：JS代码首先被解释执行，但频繁执行的代码会被JIT编译器识别并编译成机器码。JIT编译器会根据运行时观察到的类型信息进行激进优化。

  • 热点函数：被频繁调用的函数。
  • 类型反馈：JIT编译器会收集函数参数和局部变量的实际类型信息。
  • 假设与去优化（Deoptimization）：JIT会基于类型反馈做出假设（例如，某个参数总是number类型），生成高度优化的机器码。如果这些假设在运行时被打破，代码会“去优化”回解释器或不太优化的JIT层级，这会带来显著的性能开销。

• 垃圾回收（Garbage Collection）：JS引擎使用各种GC算法（如分代GC、增量GC、并发GC）来自动管理内存。GC需要遍历对象图来识别可达对象。跨语言边界的引用会增加GC的复杂性。

• 装箱（Boxing）与拆箱（Unboxing）：JavaScript的原始值（如number, boolean, string）在许多情况下可以直接存储在栈上或紧凑的内存区域。但当它们被当作对象使用时（例如调用10.toFixed()），引擎会临时创建包装对象（Number对象），这个过程称为装箱。装箱/拆箱会带来额外的内存分配和GC压力。

了解这些内部机制至关重要，因为Wasm GC对象与JS交互时，往往会触及这些优化机制的“痛点”。

3. Wasm GC 与 JavaScript 之间共享对象指针的机制

Wasm GC对象与JS对象之间的交互是双向的：

1. Wasm对象暴露给JS：当Wasm函数返回一个Wasm GC对象的引用（如structref、arrayref）时，这个引用会跨越边界，在JS中表现为一个宿主引用（HostRef）对象。这个HostRef对象是一个特殊的JS对象，它包装了底层的Wasm GC引用，并提供了类似JS对象的属性访问接口。
2. JS对象传递给Wasm：JS对象可以通过externref类型传递给Wasm。externref是Wasm中可以持有任意JS值的类型，它是对JS值的“不透明”引用。Wasm可以存储、传递和比较externref，但不能直接访问其内部结构。如果Wasm需要访问JS对象的属性或调用方法，它需要通过Wasm的call_indirect或call_ref指令调用JS导入函数。

类型转换与桥接开销：

以下表格总结了主要的类型转换机制和潜在开销：

方向	Wasm 类型	JS 类型	机制	潜在开销
Wasm -> JS	structref	JS Object (HostRef)	引擎自动创建JS包装对象（HostRef），提供属性访问器。	1. JS包装对象创建开销。 2. 跨语言边界调用开销（Get/Set属性时）。 3. JIT去优化风险（见下文）。 4. GC协调开销。
Wasm -> JS	arrayref	JS Array (HostRef)	引擎自动创建JS包装数组（HostRef），提供索引访问器。	1. JS包装对象创建开销。 2. 跨语言边界调用开销（Get/Set元素时）。 3. JIT去优化风险。 4. GC协调开销。
JS -> Wasm	任意 JS 值	externref	JS值被包装成externref。Wasm只能存储、传递和比较。	1. externref包装开销。 2. Wasm无法直接访问JS对象内部，需要通过Wasm导入的JS函数进行回调，导致额外的跨语言边界调用开销。 3. JIT去优化风险（当externref被强制转换为Wasm GC类型时，如果未来提案支持）。
JS -> Wasm	Wasm HostRef 对象	structref/arrayref	Wasm HostRef 对象在传递回Wasm时，其内部的Wasm GC引用被取出。	1. 引用类型检查（确保是有效的Wasm GC对象）。 2. 没有额外的包装/解包装，因为HostRef已经持有了原生引用。但频繁的跨边界调用仍有开销。
Wasm <-> Wasm	Wasm GC 类型	Wasm GC 类型	纯Wasm操作，直接内存访问，无JS交互开销。	无（这是Wasm GC设计的核心优势）。

Wasm GC对象在JS中的访问：

当Wasm structref或arrayref对象被暴露给JS时，JS引擎会创建一个特殊的“HostRef”对象。这个HostRef对象有几个关键特性：

• 代理访问：HostRef对象会代理对Wasm对象字段或元素的访问。例如，p1.x的访问会触发一个内部的跨语言调用，去Wasm运行时读取p1对象的x字段。
• 隐藏类：HostRef对象本身也有其隐藏类。如果Wasm导出了多种结构体，那么JS中可能会出现多种HostRef的隐藏类。
• 原型链：HostRef对象通常会有一个原型，上面可能定义了一些通用的方法。

// 假设Wasm模块导出了一个名为Point的结构体
// 在JS中接收Wasm Point对象
let wasmPoint = exports.createPoint(1, 2);

// JS访问Wasm Point的属性
console.log(wasmPoint.x); // 触发内部跨语言调用，读取Wasm Point的x字段
wasmPoint.y = 5;         // 触发内部跨语言调用，写入Wasm Point的y字段

这种“魔法”般的访问背后，正是性能损耗的温床。

4. 性能损耗分析：共享堆对象指针的挑战

Wasm GC对象与JS环境交互的性能损耗主要来源于以下几个方面：

4.1. 类型转换与桥接开销 (Type Conversion and Bridging Overhead)

当Wasm GC对象被暴露给JavaScript时，JS引擎并不能直接操作Wasm的内存布局。Wasm的结构体和数组在内存中是紧凑排列的，类似于C语言的结构体。而JavaScript对象通常有更复杂的内部结构，包括隐藏类、属性字典等。

因此，JS引擎需要为每个Wasm GC对象创建一个JS包装对象 (HostRef)。这个包装对象充当了Wasm原生对象和JS环境之间的桥梁。

• 创建包装对象的开销：每次Wasm GC对象首次跨越边界进入JS时，都需要分配一个新的JS包装对象。虽然这个包装对象本身可能很小，但频繁的创建和销毁仍然会增加GC压力和内存分配的延迟。

  // Wasm函数返回一个新的Point对象
  (func $create_point (param $x i32) (param $y i32) (result (ref $point))
    (struct.new $point (local.get $x) (local.get $y))
  )
  
  // JS中调用
  function createManyPoints() {
      for (let i = 0; i < 10000; i++) {
          let p = exports.createPoint(i, i * 2); // 每次都会创建一个JS包装对象
          // ... 使用 p ...
      }
  }

  如果Wasm对象被频繁创建并传递给JS，这个开销会累积。

• 属性/元素访问开销：当JS代码访问Wasm包装对象的属性（如wasmPoint.x）或元素（如wasmArray[0]）时，实际上会触发一个内部的跨语言边界调用。这个调用需要JS引擎进行：

  1. 类型检查：确认这是一个有效的Wasm包装对象。
  2. 获取Wasm引用：从JS包装对象中提取底层的Wasm GC引用。
  3. Wasm运行时调用：调用Wasm运行时内部的指令（如struct.get或array.get）来读取数据。
  4. 结果转换：将Wasm返回的值（如i32）转换为对应的JS值。
     这个过程涉及上下文切换、栈帧转换和额外的指令执行，比直接访问JS原生对象的属性要慢得多。

  // JS中访问Wasm Point的属性
  function getXCoordinate(p) {
      return p.x; // 每次访问都会有跨语言边界开销
  }
  
  let wasmPoint = exports.createPoint(100, 200);
  let totalX = 0;
  for (let i = 0; i < 10000; i++) {
      totalX += getXCoordinate(wasmPoint); // 10000次跨语言边界调用
  }

  对于性能敏感的循环，这种频繁的跨边界访问是主要的性能瓶颈。

4.2. JIT 优化障碍 (JIT Optimization Barriers)

JavaScript引擎的JIT编译器依赖于类型预测来生成高效的机器码。当Wasm GC对象介入时，可能会干扰JIT的优化，导致代码去优化。

• 类型污染 (Type Pollution)：

  • 多态性 (Polymorphism)：如果一个JS函数有时接收原生的JS对象，有时接收Wasm包装对象，JIT编译器会发现该参数是多态的。多态站点（polymorphic site）的优化效果通常不如单态站点（monomorphic site）。例如：

    function processPoint(p) {
        return p.x + p.y;
    }
    
    let jsPoint = { x: 1, y: 2 };
    let wasmPoint = exports.createPoint(3, 4);
    
    // 频繁调用 processPoint
    for (let i = 0; i < 10000; i++) {
        if (i % 2 === 0) {
            processPoint(jsPoint);    // JIT看到JS对象
        } else {
            processPoint(wasmPoint); // JIT看到Wasm包装对象
        }
    }

    在这种情况下，JIT编译器很难生成一个对两种对象都高度优化的版本，它可能会退化到更通用的代码路径，或者在每次调用时进行类型检查和分派。

  • externref的通用性：当JS对象被包装成externref传递到Wasm时，Wasm内部对externref的操作是通用的。如果Wasm函数接收一个externref，然后通过JS导入函数回调JS，JIT编译器在处理这个回调时，可能无法预知externref实际持有的是哪种JS对象，从而导致去优化。

• 去优化 (Deoptimization)：JIT编译器基于对代码行为的假设（例如，某个变量总是特定类型）进行优化。如果这些假设在运行时被打破（例如，一个函数参数突然从JS对象变成了Wasm包装对象），JIT编译的代码就会被抛弃，执行会回退到解释器或较低层级的JIT。去优化是一个非常昂贵的操作，因为它涉及：

  1. 停止执行当前优化的机器码。
  2. 重建解释器栈帧。
  3. 重新开始解释执行或重新编译。
     频繁的去优化会严重损害性能。Wasm GC对象作为“外来”类型，很容易打破JIT对JS原生类型的假设。

4.3. 垃圾回收器交互开销 (Garbage Collector Interaction Overhead)

浏览器环境中存在两个主要的垃圾回收器：JavaScript引擎的GC和WebAssembly GC运行时的GC。它们需要协同工作以确保所有可达对象都能被正确回收。

• 跨GC Rooting：JS对象可以引用Wasm GC对象，反之亦然。为了防止GC过早回收对象，两个GC必须互相“知道”对方持有的引用。

  • 当JS包装对象引用Wasm GC对象时，JS GC需要将这个Wasm GC对象标记为可达。
  • 当Wasm GC对象引用JS对象（通过externref）时，Wasm GC需要将这个JS对象标记为可达。
    这种交叉引用增加了GC遍历对象图的复杂性。

• 写屏障 (Write Barriers)：为了有效地进行增量或并发GC，当一个对象字段被修改为引用另一个对象时，通常需要一个“写屏障”来通知GC。跨语言边界的写操作尤其需要注意：

  • JS代码修改Wasm包装对象的属性，使其引用新的JS对象或Wasm对象。
  • Wasm代码修改其结构体或数组字段，使其引用新的JS对象（externref）或Wasm对象。
    这些写屏障的开销虽然通常很小，但在高频度的更新场景下会累积。

• GC协同与暂停：尽管现代浏览器GC都是增量和并发的，但GC根的遍历和标记阶段仍然可能需要短暂停顿。如果两个GC系统需要协调才能完成一次完整的回收周期，可能会导致更长的总暂停时间或更复杂的协调逻辑，从而影响应用的响应性。

• 内存布局差异：Wasm GC对象通常是紧凑的、C-like的内存布局。而JS对象的内存布局可能更稀疏，包含隐藏类指针、属性字典指针等。当JS访问Wasm对象时，即使数据被正确获取，也可能因为内存访问模式不一致而影响CPU缓存效率。

4.4. 内存布局与缓存效率 (Memory Layout and Cache Efficiency)

• Wasm对象的紧凑性：Wasm GC对象（structref和arrayref）被设计为具有紧凑的内存布局。例如，一个Point结构体 { x: i32, y: i32 } 会直接存储两个i32，占用8字节。数组也是连续的内存块。这种布局非常有利于CPU缓存，因为相关数据通常存储在一起。
• JS对象的间接性：当JS通过其包装对象访问Wasm对象的字段时，会引入额外的间接性：
  JS_Wrapper_Object -> Wasm_GC_Reference -> Wasm_GC_Object_Data
  每次属性访问都需要两次或三次内存解引用，这比直接访问JS原生对象的字段要慢。

• 缓存失效率：如果JS代码在一个循环中频繁地访问Wasm包装对象的多个属性，由于每次访问都涉及跨语言边界的调用和潜在的内存间接性，CPU缓存可能无法有效地预取数据，导致缓存失效率增加，从而降低性能。

  // 假设有一个Wasm Point数组，元素是Wasm Point对象
  let wasmPointsArray = exports.createPointArray(10000);
  for (let i = 0; i < 10000; i++) {
      exports.setPointArrayElement(wasmPointsArray, i, exports.createPoint(i, i * 2));
  }
  
  // JS遍历并访问数组元素
  function calculateTotalDistance(points) {
      let totalDistance = 0;
      for (let i = 0; i < points.length; i++) { // points.length 也是跨语言调用
          let p = points[i]; // 每次访问数组元素都是跨语言调用
          totalDistance += Math.sqrt(p.x * p.x + p.y * p.y); // 每次访问 p.x 和 p.y 都是跨语言调用
      }
      return totalDistance;
  }
  calculateTotalDistance(wasmPointsArray);

  这个例子中，points.length、points[i]、p.x、p.y 都涉及跨语言边界调用，对缓存性能影响巨大。

4.5. 安全性检查开销 (Security Check Overhead)

WebAssembly是一个沙盒环境，对内存访问有严格的边界检查和类型安全保证。当Wasm GC对象跨越到JS时，JS引擎需要确保对其的访问是安全的，并且符合Wasm内部的类型系统。

• JS访问Wasm对象：JS引擎在代理访问Wasm对象的属性或元素时，会进行内部检查，以确保：

  1. 引用的Wasm对象仍然存活（未被GC回收）。
  2. 属性或索引是有效的（例如，数组索引未越界）。
  3. 类型是正确的（例如，尝试访问Point的x字段时，确保对象确实是Point类型）。
     这些运行时检查虽然保障了安全性，但也增加了每次访问的开销。

• Wasm接收JS对象 (externref)：当JS对象通过externref传递给Wasm时，Wasm对它来说是一个不透明的引用。Wasm无法直接访问其内部。如果Wasm需要与JS对象交互，它必须通过Wasm导入的JS函数回调JS。这些回调本身就是跨语言边界调用，并伴随其自身的开销和JIT去优化风险。

5. 优化策略与最佳实践

理解了性能损耗的来源，我们就能有针对性地制定优化策略。核心思想是：最小化跨语言边界的交互，并最大限度地利用各自环境的优势。

5.1. 最小化跨语言边界调用 (Minimize Cross-Language Boundary Calls)

这是最重要也是最直接的优化策略。

• 批量操作 (Batching Operations)：
  与其在循环中频繁地进行单个字段的读写，不如设计Wasm函数，一次性处理一批数据或执行更复杂的逻辑。

  // BAD: 频繁跨边界访问
  function updatePointsBad(wasmPointsArray) {
      for (let i = 0; i < wasmPointsArray.length; i++) {
          wasmPointsArray[i].x += 1;
          wasmPointsArray[i].y += 2;
      }
  }
  
  // GOOD: Wasm函数批量更新
  // Wasm函数 (伪代码):
  // (func $update_points_batch (param $arr (ref $point_array)) (param $dx i32) (param $dy i32))
  //   (local $len i32)
  //   (array.len $point_array (local.get $arr)) (local.set $len)
  //   (loop $loop
  //     (local.get $i) (local.get $len) (i32.ge_s) (br_if $break)
  //     ;; 获取当前Point
  //     (local.get $arr) (local.get $i) (array.get $point_array) (local.set $current_point)
  //     ;; 更新x
  //     (local.get $current_point) (struct.get $point $x) (local.get $dx) (i32.add)
  //     (local.get $current_point) (struct.set $point $x)
  //     ;; 更新y
  //     (local.get $current_point) (struct.get $point $y) (local.get $dy) (i32.add)
  //     (local.get $current_point) (struct.set $point $y)
  //     (local.get $i) (i32.const 1) (i32.add) (local.set $i)
  //     (br $loop)
  //   )
  // )
  
  // JS中调用批量更新函数
  exports.updatePointsBatch(wasmPointsArray, 1, 2); // 一次跨边界调用完成所有更新

• 将计算“下推”到Wasm (Push Computation Down to Wasm)：
  如果一段计算逻辑主要操作Wasm GC对象，那么这段逻辑应该完全在Wasm中实现和执行。只在需要时将最终结果或摘要数据传回JS。

5.2. 避免频繁的对象创建与销毁 (Avoid Frequent Object Creation and Destruction)

• 对象池 (Object Pooling)：
  对于生命周期较短但频繁使用的Wasm GC对象，可以在Wasm内部实现一个对象池。每次需要新对象时，从池中获取；不再使用时，归还到池中，而不是让GC回收。这减少了GC压力和JS包装对象的创建。
• 重用现有对象：
  尽可能地重用Wasm GC对象。例如，更新一个Vec3对象的字段，而不是每次都创建一个新的Vec3对象。

5.3. 使用共享内存（WebAssembly.Memory）处理大量数据 (Utilize Shared Memory (WebAssembly.Memory) for Large Data)

对于纯数值数据（如顶点坐标、纹理数据、音频缓冲区），WebAssembly.Memory仍然是最高效的共享机制。

• 数据平面 (Data Plane)：将大量基础数据存储在Wasm线性内存中。JS和Wasm都可以通过Float32Array、Int32Array等ArrayBuffer视图直接访问和修改这些数据，而无需任何类型转换或GC交互。
• 对象平面 (Object Plane)：Wasm GC对象可以引用线性内存中的数据。例如，一个Wasm Mesh结构体可以包含一个指向线性内存中顶点缓冲区的指针（i32偏移量）。

  ;; 定义一个Mesh结构体，包含顶点缓冲区偏移量和顶点数量
  (type $mesh (struct (field $vertex_buffer_ptr i32) (field $vertex_count i32)))

  这种方式结合了Wasm GC的对象管理能力和线性内存的零拷贝效率。

5.4. 谨慎设计共享对象的接口 (Carefully Design Shared Object Interfaces)

• 最小化暴露：只向JS暴露Wasm GC对象中绝对必要的字段和方法。避免暴露内部实现细节。
• Plain Old Data (POD) 类型：如果Wasm结构体只是为了在JS和Wasm之间传递简单数据，尽量使其成为POD类型（只包含基本数值类型），这可以简化JS引擎的包装逻辑。
• Wasm数组 vs. JS数组：对于同构集合，优先在Wasm中使用arrayref。如果需要传递到JS，考虑传递其线性内存的视图（如果数据是数值），或者传递一个Wasm函数来迭代访问，而不是将整个arrayref暴露给JS进行逐元素访问。

5.5. 类型特化与单态性 (Type Specialization and Monomorphism)

• 隔离Wasm包装对象：在JS代码中，尽量将与Wasm包装对象交互的逻辑与处理原生JS对象的逻辑分离。

  // BAD: 混合类型，可能导致JIT去优化
  function renderObject(obj) {
      // obj 可能是 JS { x, y } 或 Wasm Point的包装对象
      context.fillRect(obj.x, obj.y, 10, 10);
  }
  
  // GOOD: 显式区分或使用专门的函数
  function renderJsObject(obj) { /* ... */ }
  function renderWasmObject(wasmPoint) {
      context.fillRect(wasmPoint.x, wasmPoint.y, 10, 10);
  }

  通过这种方式，JIT编译器可以为renderWasmObject函数生成针对Wasm包装对象的高度优化代码（因为它总是接收同一类型的对象），减少去优化。

5.6. 利用 Wasm GC 的原生类型 (Leverage Native Wasm GC Types)

• 内部数据结构首选Wasm GC：如果复杂数据结构主要在Wasm内部被操作，那么就应该定义为Wasm struct或array。这利用了Wasm GC的优势，避免了手动内存管理和JS GC的额外负担。
• JS-Wasm 边界作为 API 边界：将Wasm模块视为一个黑盒API。JS只调用其导出的函数，传入基本类型或externref，并接收基本类型或Wasm GC对象作为结果。Wasm GC对象作为返回值时，应被视为不透明的句柄，JS只通过Wasm导出的方法对其进行操作，而不是直接访问其内部属性。

6. 案例分析：游戏引擎中的实体组件系统 (ECS)

假设我们正在构建一个Web游戏引擎，其中：

• 物理引擎：用C++编写，编译到Wasm，负责管理游戏实体的物理属性（位置、速度、碰撞体等）。
• 渲染引擎：用TypeScript编写，运行在JS中，负责将实体渲染到屏幕上。
• ECS (Entity-Component-System)：核心架构，实体由组件组成。

Wasm GC 集成前的挑战：
在Wasm GC之前，C++编译的物理引擎需要将所有物理组件数据（如Vec3用于位置、Quaternion用于旋转）存储在线性内存中，并通过数字索引或指针（Wasm i32）来引用。当JS需要访问这些数据时，需要：

1. 传递Wasm线性内存的视图 (Float32Array)。
2. 通过索引计算偏移量来读取/写入数据。
   这种方式虽然高效，但代码可读性差，且容易出错。

Wasm GC 集成后的设计：
我们可以将物理组件定义为Wasm struct：

;; Vec3 结构体
(type $vec3 (struct (field $x f32) (field $y f32) (field $z f32)))

;; TransformComponent 包含位置、旋转、缩放
(type $transform_component (struct
  (field $position (ref $vec3))
  (field $rotation (ref $vec3)) ;; 简化为Vec3，实际可能是Quaternion
  (field $scale (ref $vec3))
))

;; RigidBodyComponent 包含质量、速度、角速度
(type $rigid_body_component (struct
  (field $mass f32)
  (field $velocity (ref $vec3))
  (field $angular_velocity (ref $vec3))
))

(module
  ;; ... 类型定义 ...
  (func $create_vec3 (param $x f32) (param $y f32) (param $z f32) (result (ref $vec3))
    (struct.new $vec3 (local.get $x) (local.get $y) (local.get $z))
  )

  (func $get_vec3_x (param $v (ref $vec3)) (result f32)
    (local.get $v) (struct.get $vec3 $x)
  )

  (func $set_vec3_x (param $v (ref $vec3)) (param $val f32)
    (local.get $v) (local.get $val) (struct.set $vec3 $x)
  )

  ;; 导出函数用于创建和访问组件
  (export "createVec3" (func $create_vec3))
  (export "getVec3X" (func $get_vec3_x))
  (export "setVec3X" (func $set_vec3_x))
  ;; ... 其他组件的创建和访问函数 ...
)

性能考量与优化：

1. 物理模拟循环：

   • 问题：物理模拟是一个高频、计算密集型任务。如果每帧都将所有实体的物理组件从Wasm传递到JS，让JS更新，再传回Wasm，性能将是灾难性的。
   • 优化：整个物理模拟循环（包括碰撞检测、力学计算、位置更新）完全在Wasm内部完成。Wasm直接操作其原生Vec3、TransformComponent等对象。避免在模拟过程中与JS交互。

2. 渲染数据同步：

   • 问题：JS渲染器需要获取每个实体的最新位置和旋转信息。如果渲染器遍历所有Wasm TransformComponent包装对象，并逐个访问position.x、position.y等，性能会很差。
   • 优化：
     • 批量数据导出：Wasm提供一个函数，可以将所有实体的TransformComponent的位置和旋转数据，一次性写入Wasm线性内存中的一个特定区域。

       ;; (func $export_all_transforms (param $offset i32))
       ;; 遍历所有实体，将(x,y,z,qx,qy,qz,qw)写入线性内存从$offset开始的位置

       JS通过Float32Array视图直接读取这块线性内存，实现零拷贝数据同步。

     • 脏标记 (Dirty Flags)：Wasm只在组件数据发生变化时，才标记为“脏”，并提供函数让JS查询哪些组件需要更新。JS只同步脏数据，减少数据传输量。

3. UI交互：

   • 问题：JS UI可能需要显示某个实体的当前速度或允许用户修改其位置。
   • 优化：
     • 单点访问：对于单个实体的查询或修改，可以通过Wasm函数进行。例如：wasmExports.getEntityPosition(entityId)。虽然这涉及跨边界调用，但由于是低频的用户交互，其性能开销通常可以接受。
     • 谨慎修改：当JS修改Wasm GC对象时，如entityTransform.position.x = newValue，每次修改都是一次跨边界调用。对于高频修改，应考虑提供Wasm函数进行批量修改，或者直接操作线性内存。

总结表格：ECS中的Wasm GC对象交互优化

场景	交互模式	性能挑战	推荐优化策略	理由
物理模拟	Wasm内部操作Wasm TransformComponent等	无JS交互，纯Wasm执行	完全在Wasm内部执行物理模拟	避免所有跨语言边界开销，利用Wasm的紧凑内存布局和原生GC。
渲染数据同步	JS读取Wasm TransformComponent的位置和旋转	频繁的属性访问导致大量跨边界调用和JIT去优化	Wasm提供函数，将所有所需数据批量写入线性内存，JS通过ArrayBuffer视图读取。	零拷贝数据传输，将多次跨边界调用合并为一次。避免JIT去优化。
UI查询/修改	JS获取/设置单个Wasm TransformComponent属性	单次跨边界调用开销，若频繁则累积	封装Wasm函数，进行单点查询/修改；低频操作可接受。	UI交互通常不在性能热点路径，可接受少量跨边界调用。
对象生命周期	Wasm创建/销毁 Vec3、TransformComponent等	频繁的Wasm GC对象创建可能导致JS包装对象创建和GC压力	Wasm内部使用对象池管理频繁创建的组件；重用现有对象。	减少GC压力和JS包装对象的创建/销毁开销。

通过上述优化策略，我们可以充分发挥Wasm GC在内存管理和原生对象操作方面的优势，同时避免与JavaScript交互时可能产生的性能瓶颈。

7. 未来展望

WebAssembly GC提案仅仅是WebAssembly生态系统演进的开始。未来，我们可以期待以下发展：

• js-type 提案的成熟：js-type提案旨在提供Wasm和JS之间更深层次的类型集成，允许Wasm直接引用JS类型（例如Array、Promise），并进行更安全的类型转换和检查。这将可能减少externref的通用性带来的JIT去优化问题。
• 引擎优化：浏览器引擎将持续优化Wasm GC对象与JS的交互。例如，JIT编译器可能会为常见的Wasm GC对象类型生成更快的专门代码路径，甚至可能实现某种形式的“零成本”抽象。
• 统一垃圾回收：长期来看，Wasm GC和JS GC可能会更紧密地集成，甚至可能走向某种程度的统一，从而减少GC协调的复杂性和开销。
• 字符串类型 (stringref)：stringref提案将允许Wasm直接操作字符串，进一步减少字符串处理时的跨语言开销。

这些未来的发展将进一步提升Wasm与JavaScript的互操作性性能，使得在Web平台上构建高性能、复杂应用变得更加可行和高效。

8. 思考与展望

WebAssembly GC提案为Web平台带来了革命性的内存管理能力，使得高级语言能够以更自然、更高效的方式运行在浏览器中。然而，这种能力的实现并非没有代价。Wasm GC对象与JavaScript之间共享堆对象指针，引入了类型转换、JIT优化障碍、GC协同以及内存布局等多方面的性能损耗。

作为开发者，我们必须深刻理解这些潜在的瓶颈，并采取积极的策略来规避它们。核心原则始终是：最小化跨语言边界的交互，将计算和数据处理尽可能地限制在性能最适合的环境中。对于数值密集型或对象密集型操作，优先在Wasm中处理；对于UI交互或与Web API的集成，则在JavaScript中处理。通过精心设计API边界和数据流，我们能够构建出既能发挥WebAssembly极致性能，又能保持JavaScript灵活性的高性能Web应用。

性能优化是一个永无止境的旅程，但有了WebAssembly GC，我们手中的工具箱无疑变得更加强大。让我们以开放的心态，迎接Web平台高性能计算的全新时代。

感谢大家的聆听！