このページは Cloud Translation API によって翻訳されました。

WebAssembly ガベージコレクション（WasmGC）を Chrome でデフォルトで有効化

Thomas Steiner

プログラミング言語には、ガベージコレクションを使用するプログラミング言語と、手動のメモリ管理が必要なプログラミング言語の 2 種類があります。前者の例としては、Kotlin、PHP、Java などがあります。後者の例としては、C、C++、Rust などがあります。一般に、高水準プログラミング言語には、ガベージコレクションが標準機能として含まれています。このブログ投稿では、このようなガベージコレクションを行うプログラミング言語と、それらを WebAssembly（Wasm）にコンパイルする方法について説明します。ガベージコレクション（GC）とは、そもそも何でしょうか。

対応ブラウザ

ガベージコレクション

簡単に説明すると、ガベージコレクションとは、プログラムによって割り当てられたが、参照されなくなったメモリの再利用を試みることです。このようなメモリはガベージと呼ばれます。ガベージコレクションを実装する方法は数多くあります。そのうちの 1 つが参照カウントです。これは、メモリ内のオブジェクトへの参照数をカウントすることを目的としています。オブジェクトへの参照がなくなったら、使用されなくなったとしてマークされ、ガベージコレクションの対象になります。PHP のガベージコレクタは参照カウントを使用します。Xdebug 拡張機能の xdebug_debug_zval() 関数を使用すると、内部を覗くことができます。次の PHP プログラムについて考えてみましょう。

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

このプログラムでは、文字列にキャストされた乱数を a という新しい変数に割り当てます。次に、2 つの新しい変数 b と c を作成し、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 コンパイラと Zend エグゼキュータで構成される Zend 仮想マシン（VM）で構成されています。C などの他の高水準言語で実装されている PHP などの言語には、Intel や ARM などの特定のアーキテクチャをターゲットとする最適化が一般的に含まれており、アーキテクチャごとに異なるバックエンドが求められます。このコンテキストでは、Wasm は新しいアーキテクチャを表します。VM にアーキテクチャ固有のコード（JIT コンパイルや AOT コンパイルなど）がある場合は、デベロッパーは新しいアーキテクチャの JIT/AOT 用にバックエンドを実装します。多くの場合、コードベースの大部分は新しいアーキテクチャごとに再コンパイルできるため、このアプローチは非常に理にかなっています。

Wasm は低レベルであるため、同じアプローチを試すことは自然なことです。つまり、パーサー、ライブラリサポート、ガベージコレクション、最適化ツールを含むメインの VM コードを Wasm に再コンパイルし、必要に応じて Wasm 用の JIT または AOT バックエンドを実装します。これは Wasm MVP 以降可能であり、多くの場合、実際にうまく機能します。実際、WordPress Playground は Wasm にコンパイルされた PHP で動作しています。このプロジェクトについて詳しくは、WordPress Playground と WebAssembly を使用してブラウザ内 WordPress エクスペリエンスを構築するをご覧ください。

ただし、PHP Wasm はホスト言語 JavaScript のコンテキストでブラウザで実行されます。Chrome では、JavaScript と Wasm は V8 で実行されます。V8 は、ECMA-262 で指定されているように ECMAScript を実装する Google のオープンソース JavaScript エンジンです。また、V8 にはすでにガベージコレクタがあります。つまり、Wasm にコンパイルされた PHP などを使用するデベロッパーは、ポートされた言語（PHP）のガベージコレクタ実装を、すでにガベージコレクタが存在するブラウザに配布することになります。これは、言うまでもなく無駄です。そこで役立つのが WasmGC です。

Wasm モジュールが Wasm のリニアメモリ上に独自の GC を構築できるようにする従来のアプローチのもう 1 つの問題は、Wasm 独自のガベージコレクタと、Wasm にコンパイルされた言語の上に構築されたガベージコレクタの間に相互作用がないため、メモリリークや非効率的な収集の試行などの問題が発生する傾向があることです。Wasm モジュールが既存の組み込み GC を再利用できるようにすると、これらの問題を回避できます。

WasmGC を使用したプログラミング言語の新しいランタイムへの移植

WasmGC は、WebAssembly コミュニティグループの提案です。現在の Wasm MVP 実装では、リニアメモリ内の数値（整数と浮動小数点数）のみを処理できます。参照型の提案がリリースされると、Wasm は外部参照も保持できるようになります。WasmGC に構造体と配列のヒープ型が追加され、非線形メモリ割り当てがサポートされるようになりました。各 WasmGC オブジェクトには固定の型と構造があるため、VM は JavaScript などの動的言語で発生するdeoptimizationsのリスクなしで、フィールドにアクセスする効率的なコードを簡単に生成できます。この提案により、構造体と配列のヒープ型を介して、高レベルのマネージド言語を WebAssembly に効率的にサポートします。これにより、Wasm をターゲットとする言語コンパイラをホスト VM のガベージコレクタと統合できます。簡単に説明すると、WasmGC では、プログラミング言語を Wasm に移植する場合、プログラミング言語のガベージコレクタを移植する必要はなく、代わりに既存のガベージコレクタを使用できます。

この改善による実際の影響を確認するため、Chrome の Wasm チームは、C、Rust、Java から Fannkuch ベンチマーク（実行時にデータ構造を割り当てる）のバージョンをコンパイルしました。C と Rust のバイナリは、さまざまなコンパイラフラグに応じて 6.1 K～9.6 K の範囲になりますが、Java バージョンは 2.3 K とかなり小さくなります。C と Rust にはガベージコレクタは含まれていませんが、メモリを管理するために malloc/free をバンドルしています。Java がここで小さい理由は、メモリ管理コードをバンドルする必要がまったくないためです。これは 1 つの具体的な例にすぎませんが、WasmGC バイナリが非常に小さくなる可能性を示しています。これは、サイズの最適化に関する大きな作業を開始する前です。

WasmGC に移植されたプログラミング言語の動作を確認する

Kotlin Wasm

WasmGC によって Wasm に移植された最初のプログラミング言語の 1 つは、Kotlin/Wasm 形式の Kotlin です。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 コードは基本的に JavaScript OM API を Kotlin に変換したもので構成されているため、何の意味があるのかと疑問に思うかもしれません。Compose マルチプラットフォームと組み合わせると、デベロッパーは Android Kotlin アプリ用にすでに作成した UI を基にビルドできるため、さらに便利になります。Kotlin チームが提供した Kotlin/Wasm 画像ビューアのデモで、この機能の初期段階をご確認ください。また、ソースコードもご覧ください。

警告: Kotlin/Wasm のステータスはアルファ版、Compose マルチプラットフォームのステータスは試験運用版です。Kotlin/Wasm はデベロッパーの責任において使用できますが、移行に関する問題に備える必要があります。Compose Multiplatform は随時変更される可能性があり、評価目的でのみ使用してください。Kotlin/Wasm 画像ビューアのデモでは現在、Compose マルチプラットフォームで Kotlin/Wasm を使用しています。このデモでは、canvas に完全にレンダリングされ、ユーザー補助ツリーを作成するために使用できる有意な DOM ツリーがありません。つまり、視覚障がいのあるユーザーは完全にアクセスできず、ページ内検索、翻訳、テキストの選択、拡張機能、ズーム、テキストフラグメントへのリンクなどの重要なブラウザ機能が使用できなくなります。

Dart と Flutter

Google の Dart チームと Flutter チームも、WasmGC のサポートを準備しています。Dart から Wasm へのコンパイルはほぼ完了しており、チームは WebAssembly にコンパイルされた Flutter ウェブアプリケーションを配信するためのツールのサポートに取り組んでいます。作業の現在の状況については、Flutter のドキュメントをご覧ください。次のデモは Flutter WasmGC プレビュー版です。

警告: Dart WasmGC コンパイルと WasmGC を使用した Flutter Web はプレビュー版であり、評価目的でのみ使用してください。Flutter Web WasmGC プレビューデモでは現在、canvas に完全にレンダリングする Flutter の CanvasKit レンダラが使用されています。つまり、ページ内検索、翻訳、テキスト選択、拡張機能、テキストフラグメントへのリンクなどの重要なブラウザ機能が使用できなくなります。

WasmGC の詳細

このブログ投稿では、WasmGC の概要を説明しました。この機能について詳しくは、以下のリンクをご覧ください。

謝辞

この記事は、Matthias Liedtke、Adam Klein、Joshua Bell、Alon Zakai、Jakob Kummerow、Clemens Backes、Emanuel Ziegler、Rachel Andrew によるレビューを経て公開されました。