2024年Wasm GC正式リリース。Reference Type+struct/array管理型+JavaScript GC統合+Java/Kotlin/Dart/OCamlコンパイル先対応+Bundle Size削減+Memory Leak防止。
WebAssembly Garbage Collectionは2024年にChrome 119+/Firefox 120+でフル対応となったWebAssembly GC(Garbage Collection)正式リリース仕様。Wasm Phase 4昇格で、Reference Type+struct/array管理型をWebAssemblyネイティブに導入し、JavaScript GCと統合した次世代仕様。従来のWebAssemblyはLinear Memory(線形メモリ)モデル中心で、C/C++/Rust等のManual Memory Management言語に最適化されていたが、Wasm GCの導入によりJava・Kotlin・Dart・OCaml・Scala.js等のGC前提言語が WebAssembly コンパイル先として有効になった点が革命的。Kotlin/Wasm(JetBrains 2024年GA)・Dart Web(Flutter/Wasm)・Java(TeaVM等)・OCaml(js_of_ocaml後継)が Wasm GC で動作可能となり、JavaScript以外の言語でWebアプリ開発が現実的選択肢に。Bundle Sizeも従来の Wasm Manual GC実装(Boehm GC等)を排除することで30-50%削減、ブラウザネイティブGCの最適化恩恵が直接得られる。
struct/array のManaged型、JavaScript GCで自動メモリ管理| 項目 | Wasm GC | Wasm MVP(Linear Memory) | JavaScript GC | Java JVM GC |
|---|
| Memory Management | Browser GC | Manual(C/C++)/Lib GC | Browser GC | JVM GC |
| Reference Type | ○ | × | ○ | ○ |
| Subtyping | ○ | × | ○ Prototype | ○ Class |
| Bundle Size | 軽量 | 重(Lib GC含む) | 0KB(Native) | JVM必要 |
| 対応言語 | Java/Kotlin/Dart/OCaml | C/C++/Rust/Go(Lib) | JavaScript | Java/Kotlin/Scala |
| Browser Support | Chrome 119+ Firefox 120+ | 全Browser | 全Browser | × Browser非対応 |
| Performance | JS GC同等 | Manual最適 | 既知 | JVM最適 |
| 学習曲線 | 中(Wasm基礎) | 高(C/C++知識) | 低 | 中(Java知識) |
;; Wasm GC使用例(WAT形式)
(module
(type $point (struct (field $x i32) (field $y i32)))
(func $create-point (param $x i32) (param $y i32) (result (ref $point))
(struct.new $point (local.get $x) (local.get $y)))
(func $get-x (param (ref $point)) (result i32)
(struct.get $point $x (local.get 0)))
)
// Kotlin/Wasm(2024 GA)
fun main() {
val list = listOf(1, 2, 3, 4, 5)
val sum = list.sum()
console.log("Sum: $sum") // Wasm GC で自動管理
}
WebAssembly GCはWeb開発者向けの重要技術仕様で、自作PCの選択とは関係しないが、Web Frontend開発の選択肢拡大に貢献する革命的進化。jisaku.com Web Frontend(Next.js 16+TypeScript)では現状Wasm未使用だが、将来的に重い計算処理(画像処理・データ可視化・大量データソート等)でWasm GC採用候補となる技術。Kotlin/Wasm + Compose for Web(2024 GA)を活用すれば、Android アプリのコードを共有してWebアプリ実装可能で、コードベース共有のメリットが大きい。Dart/Flutter Web(Wasm)はFlutter モバイルアプリのコードをそのままWeb展開可能で、PWA(Progressive Web App)化が容易。一方、現実問題として、JavaScript+TypeScript の Tooling・Library Ecosystemに比べて、Wasm GC + Kotlin/Dart/OCamlのEcosystemは未熟で、本格Production採用には2-3年の成熟期間が必要見込み。jisaku.com で Wasm GC を採用する具体ユースケースは、画像処理(WebP/AVIF コーデック)・大量データソート(数十万件記事のリアルタイム検索)・暗号処理(WebCrypto+Wasm)等の Performance Critical 領域に限定される。Browser Support は Chrome 119+/Firefox 120+(2023年Q4)で2026年5月時点で十分Production採用可能、Safari TP実装中のためフルカバレッジは2025年中。
Wasm MVP(Linear Memory)との違い: MVP(2017年)は Linear Memory + Manual Management、Wasm GCは Reference Type + Browser GC統合。MVPはC/C++/Rust等のManual言語向け、Wasm GCはJava/Kotlin/Dart等のGC前提言語向け。両者並行運用可能。 JavaScript GCとの違い: JavaScript GCはJavaScript エンジン内蔵、Wasm GCはJavaScript GCを活用してWebAssemblyから利用する仕組み。Wasm GC は新規Browser GCを作るのではなく、既存JavaScript GC(V8/SpiderMonkey/JavaScriptCore)を共用する設計。
Q1: Wasm GC vs Wasm Linear Memory どちらを選ぶべき？ A: 言語次第。C/C++/Rust/Go(Manual GC言語)はLinear Memory継続、Java/Kotlin/Dart/OCaml(GC言語)はWasm GC採用。同じプロジェクト内で両者混在も可能、機能ごとに最適選択。
Q2: Performance はJavaScript と比較してどう？ A: 大半のケースでJavaScriptと同等または若干優位、極端な計算集約(数値計算等)で2-5倍速。Wasm GCの Reference Type Conversion(JavaScript ⟷ Wasm GC) のオーバーヘッドがあるため、頻繁な Cross-boundary 呼び出しは性能劣化の原因。
Q3: Production採用すべき時期は？ A: 2026-2027年以降推奨。現状はEarly Adopter段階で、Browser Compatibility・Tooling・Library Ecosystemが2-3年の成熟期間必要。jisaku.com のような商用Webサイトでは2026年中はTechnical Preview のみで、Production採用は2027年以降が安全。