Chrome 現已預設啟用 WebAssembly 垃圾收集 (WasmGC)

程式設計語言分為兩種:垃圾收集程式設計語言和需要手動記憶體管理的程式設計語言。前者範例包括 Kotlin、PHP 或 Java。後者的例子包括 C、C++ 或 Rust。一般來說,高階程式設計語言較有可能將垃圾收集設為標準功能。這篇網誌文章將著重於這類垃圾收集程式設計語言,以及如何將這些語言編譯為 WebAssembly (Wasm)。不過,垃圾收集 (通常稱為 GC) 究竟是什麼呢?

瀏覽器支援

  • Chrome:119。
  • Edge:119。
  • Firefox:120。
  • Safari:不支援。

垃圾收集

簡單來說,垃圾收集的概念就是嘗試回收程式已分配但不再參照的記憶體。這類記憶體稱為垃圾。實作垃圾回收機制的策略有很多種。其中之一就是參照計數,其目的是計算記憶體中物件參照的數量。當物件沒有其他參照時,系統會將其標示為不再使用,並準備進行垃圾收集。PHP 的垃圾收集器會使用參照計數,您可以使用 Xdebug 擴充功能的 xdebug_debug_zval() 函式,一窺其運作原理。請參考下列 PHP 程式。

<?php
  $a= (string) rand();
  $c = $b = $a;
  $b = 42;
  unset($c);
  $a = null;
?>

程式會將轉換為字串的隨機號碼指派給名為 a 的新變數。接著,它會建立兩個新變數 bc,並為其指派 a 的值。之後,它會將 b 重新指派給編號 42,然後取消設定 c。最後,它會將 a 的值設為 null。使用 xdebug_debug_zval() 為程式的每個步驟加上註解,您就能看到垃圾收集器的參照計數器運作情形。

<?php
  $a= (string) rand();
  $c = $b = $a;
  xdebug_debug_zval('a');
  $b = 42;
  xdebug_debug_zval('a');
  unset($c);
  xdebug_debug_zval('a');
  $a = null;
  xdebug_debug_zval('a');
?>

上述範例會輸出以下記錄,您可以看到每個步驟後,變數 a 的值參照數量會減少,這與程式碼序列相符。(當然,您的隨機數字會有所不同)。

a:
(refcount=3, is_ref=0)string '419796578' (length=9)
a:
(refcount=2, is_ref=0)string '419796578' (length=9)
a:
(refcount=1, is_ref=0)string '419796578' (length=9)
a:
(refcount=0, is_ref=0)null

垃圾收集還有其他挑戰,例如偵測循環,但就本文章而言,只要對參照計數有基本的瞭解即可。

程式設計語言以其他程式設計語言實作

這可能讓人覺得很難理解,但程式設計語言會在其他程式設計語言中實作。舉例來說,PHP 執行階段主要實作於 C 中。您可以查看 GitHub 上的 PHP 原始碼。PHP 的垃圾收集程式碼主要位於 zend_gc.c 檔案中。大多數開發人員會透過作業系統的套件管理工具安裝 PHP。不過,開發人員也可以從原始碼建構 PHP。舉例來說,在 Linux 環境中,步驟 ./buildconf && ./configure && make 會為 Linux 執行階段建構 PHP。但這也表示 PHP 執行階段可以為其他執行階段編譯,例如 Wasm。

將語言移植至 Wasm 執行階段的傳統方法

無論 PHP 執行的平台為何,PHP 指令碼都會編譯為相同的位元碼,並由 Zend Engine 執行。Zend Engine 是 PHP 指令碼語言的編譯器和執行階段環境。這個架構包含 Zend 虛擬機器 (VM),而 VM 則由 Zend 編譯器和 Zend 執行工具組成。以 C 等高階語言實作的 PHP 等語言,通常會針對特定架構 (例如 Intel 或 ARM) 進行最佳化,且每個架構都需要不同的後端。在這個情況下,Wasm 代表新的架構。如果 VM 有架構專屬程式碼,例如即時 (JIT) 或預先 (AOT) 編譯,開發人員也應為新架構實作 JIT/AOT 的後端。這個做法非常合理,因為程式碼庫的主要部分通常只需針對每個新架構重新編譯即可。

考量到 Wasm 的低階程度,自然會嘗試採用相同的方法:將主要的 VM 程式碼連同剖析器、程式庫支援、垃圾收集器和最佳化工具重新編譯為 Wasm,並視需要為 Wasm 實作 JIT 或 AOT 後端。自 Wasm MVP 以來,這項功能就已可行,而且在許多情況下都能順利運作。事實上,編譯為 Wasm 的 PHP 正是 WordPress Playground 的動力來源。如要進一步瞭解這個專案,請參閱「使用 WordPress Playground 和 WebAssembly 建構瀏覽器內的 WordPress 體驗」一文。

不過,PHP Wasm 會在主機語言 JavaScript 的背景下,在瀏覽器中執行。在 Chrome 中,JavaScript 和 Wasm 會在 V8 中執行,這是 Google 的開放原始碼 JavaScript 引擎,可實作 ECMA-262 中指定的 ECMAScript。V8 已具備垃圾收集器。也就是說,如果開發人員使用已編譯為 Wasm 的 PHP,最終會將移植語言 (PHP) 的垃圾收集器實作項目傳送至已具備垃圾收集器的瀏覽器,這麼做會造成浪費。這時,WasmGC 就派上用場。

舊版方法讓 Wasm 模組在 Wasm 的線性記憶體上建構自己的 GC,這會導致 Wasm 本身的垃圾收集器與編譯為 Wasm 語言的建構 GC 之間沒有互動,進而導致記憶體外洩和收集效率不佳等問題。讓 Wasm 模組重複使用現有的內建 GC 可避免這些問題。

使用 WasmGC 將程式設計語言移植至新執行階段

WasmGC 是 WebAssembly 社群群組提案。目前的 Wasm MVP 實作功能只能處理線性記憶體中的數字,也就是整數和浮點數,而隨著參照類型提案的推出,Wasm 還能保留外部參照。WasmGC 現在會新增結構體和陣列堆積類型,也就是支援非線性記憶體配置。每個 WasmGC 物件都有固定的類型和結構,因此 VM 可以輕鬆產生有效的程式碼來存取其欄位,不必擔心 JavaScript 等動態語言的不最佳化問題。因此,這項提案透過結構體和陣列堆積類型,為 WebAssembly 新增高階受管理語言的有效支援,讓以 Wasm 為目標的語言編譯器可與主機 VM 中的垃圾收集器整合。簡單來說,這表示使用 WasmGC 將程式設計語言移植至 Wasm 時,程式設計語言的垃圾收集器不再需要納入移植作業,而是可使用現有的垃圾收集器。

為驗證這項改善措施在實際情況下的影響,Chrome 的 Wasm 團隊已編譯 Fannkuch 基準測試 (會在運作時分配資料結構) 的版本,這些版本分別來自 CRustJava。C 和 Rust 二進位檔的大小可能介於 6.1 K9.6 K 之間,具體取決於各種編譯器標記,而 Java 版本的大小則只有 2.3 K,小得多!C 和 Rust 不包含垃圾收集器,但仍會內含 malloc/free 來管理記憶體,而 Java 在這裡較小的原因是因為它根本不需要內含任何記憶體管理程式碼。這只是一個具體範例,但這顯示 WasmGC 二進位檔可能非常小,即使在進行任何重大的大小最佳化工作前也是如此。

查看 WasmGC 移植的程式設計語言運作情形

Kotlin Wasm

多虧 WasmGC,Kotlin 是第一個移植至 Wasm 的程式設計語言,以 Kotlin/Wasm 的形式呈現。以下清單顯示 示範,以及 Kotlin 團隊提供的原始碼

import kotlinx.browser.document
import kotlinx.dom.appendText
import org.w3c.dom.HTMLDivElement

fun main() {
    (document.getElementById("warning") as HTMLDivElement).style.display = "none"
    document.body?.appendText("Hello, ${greet()}!")
}

fun greet() = "world"

您可能會想知道這有什麼意義,因為上述 Kotlin 程式碼基本上包含轉換為 Kotlin 的 JavaScript OM API。搭配使用 Compose Multiplatform 後,這項功能就會變得更實用,因為開發人員可以利用已為 Android Kotlin 應用程式建立的 UI 進行建構。您可以透過 Kotlin/Wasm 圖片檢視器 示範,瞭解這項功能的早期開發成果,並探索 Kotlin 團隊提供的原始碼

Dart 和 Flutter

Google 的 Dart 和 Flutter 團隊也正在準備支援 WasmGC。Dart 到 Wasm 的編譯作業已接近完成,團隊也正在開發工具,以便提供編譯為 WebAssembly 的 Flutter 網頁應用程式。如要瞭解這項工作的目前狀態,請參閱 Flutter 說明文件。以下是 Flutter WasmGC 預覽版的示範。

進一步瞭解 WasmGC

這篇網誌文章只是略微介紹 WasmGC,主要提供概略的總覽。如要進一步瞭解這項功能,請參閱下列連結:

特別銘謝

本文由 Matthias LiedtkeAdam KleinJoshua BellAlon ZakaiJakob KummerowClemens BackesEmanuel ZieglerRachel Andrew 共同審查。