さくらインターネット研究所 中田裕貴 (@chiku_wait) 実行環境に中立な WebAssemblyライブマイグレーション機構 2025/3/13 さくらインターネット研究所 テックトーク2025春 

2 中田裕貴(X: @chiku_wait) • 2022年新卒入社（研究所では珍しい新卒配属） • 北海道札幌市在住 • 公立はこだて未来大学 大学院システム情報科学研究科 博士（後期）課程1年 システムソフトウェア研究室 • システムソフトウェア研究 • 仮想化技術（VM・コンテナ）・OS・高速パケット処理技術・ カーネル内トレーシングなど • さくらと博士後期課程では、 クラウド・エッジ・デバイス間ライブマイグレーションのための実行環境を研究しています 

3 12月の9th ACM/IEEE Symposium on Edge Computing(SEC 2024) + 現在の進捗 • 大いにWIPな部分も含めてお話できたらと思います • 鋭利な質疑応答もお待ちしています https://ieeexplore.ieee.org/document/10817975 https://speakerdeck.com/chikuwait/poster-feasibility- of-runtime-neutral-wasm-instrumentation-for-edge- cloud-workload-handover 

4 • 処理内容や性能要件・外部状況に合わせて実行先を動的に変化 • 異なる計算機環境の特性を活用 • エッジ：ユーザ近傍での低遅延処理 • クラウド：高性能な計算資源の活用 • ソフトウェアはどこで動いているか分からないけど 一番最適な計算機環境で動いている • オフロードやハンドオフによる実行先変化 目指している計算機環境 地理的に分散した計算機間でのシームレスな連携 より高性能なサーバへ 処理をオフロード ユーザの移動に 合わせたハンドオフ 

5 実現に必要なソフトウェア実行環境の特性 ソフトウェア ソフトウェア ARMマシン 処理状態 X86_64サーバ 処理状態 1. アーキテクチャ中立性 • クラウド環境では高性能なx86_64、デバイス環境では省電力なARMが普及[1] • アーキテクチャの差異を吸収してソフトウェアをそのまま実行可能な環境が必要 2. 可搬性 • 要件や要求に合わせてソフトウェアの実行先が動的に変化 • 処理状態を維持したまま最適なノードに再配置し 処理途中から再開するライブマイグレーションが必要 • 異種環境間での実現によってアーキテクチャ中立性と両立 [1] J. Shuja, S. Mustafa, R. W. Ahmad, S. A. Madani, A. Gani and M. Khurram Khan, "Analysis of Vector Code Offloading Framework in Heterogeneous Cloud and Edge Architectures," IEEE Access, vol. 5, pp. 24542-24554, 2017. 

6 WebAssembly(Wasm)：アーキテクチャ中立なソフトウェア実行環境 あらゆるアーキテクチャでソフトウェアを効率的に実行可能 多様な環境で動作するVM・ 各用途に特化したランタイム実装 エッジ向けランタイム e.g., WAMR (WebAssembly Micro Runtime) エッジ環境 (ARM) クラウド環境 (x86_64) クラウド向けランタイム e.g., Wasmtime Wasmバイトコード Wasmバイトコード 低メモリ消費・ 電力消費 高速実行 … Wasmバイトコード あらゆる言語から コンパイル Rust C言語 仮想命令セットアーキテクチャ 

7 異種プラットフォーム間Wasmライブマイグレーションの難しさ 内部状態実装とランタイムのバイトコード実行最適化に強く依存 Wasmランタイム 命令やVMの標準仕様は定義されているが 実現方法は多様 ランタイムごとに最適化方式が異なる Wasm バイトコード AOT コンパイル AOT用 ライブマイグレーション ネイティブ バイナリ JIT用 ライブマイグレーション インタプリタ用 ライブマイグレーション JITコンパイル WAMR デバイス環境 Wasmバイトコード ライブマイグレーション for WAMR Wasmtime クラウド環境 Wasmバイトコード ライブマイグレーション for Wasmtime 

8 AOTコンパイルやJITコンパイルによる実行最適化によって内部状態変化 プログラム カウンタ Wasm Edge VM Wasmバイトコード H e l l o \n フレームスタック 値スタック 計算時の 数値型を格納 実行中関数の 情報を格納 文字列などの データを格納 線形メモリ プログラム カウンタ Wasm VM Wasmバイトコード H e l l o \n フレーム スタック 値スタック CPUレジスタ・ プログラムカウンタ OSスタック VM外に内部状態が散在 

9 既存のアプローチ: Wasmバイトコードへの内部状態取得コード挿入手法 (Wasabi)[2] Wasm バイトコード 改変済Wasmバイトコード 内部状態取得 コード挿入 内部状態取得 JavaScript関数 内部状態取得関数 呼び出し … local.get $p1 local.get $p2 i32.add call $hoge … … call $analysis local.get $p1 call $analysis local.get $p2 call $analysis i32.add call $analysis call $hoge call $analysis … Pros: ランタイムや最適化に非依存 Cons: アプリケーション性能低下 [2] Daniel Lehmann and Michael Pradel. Wasabi: A framework for dynamically analyzing webassembly. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’19, p. 1045–1058, New York, NY, USA, 2019. Association for Computing Machinery. • 実行前に内部状態取得コードを挿入 • ランタイムや最適化手法に非依存 • アプリケーション性能が大幅に低下 • JavaScriptで記述し Wasmバイトコードから呼び出し • 任意タイミングのライブマイグレーションでは 大量のJavaScript関数の呼び出し 

10 本研究のアプローチ：セルフホストWasmランタイムによる内部状態取得 • ライブマイグレーション機構を備えた Wasmインタプリタをセルフホスト化 • 任意のホストWasmランタイムで セルフホストインタプリタを用いてバイトコード実行 • ランタイム・最適化手法に依存した 内部状態取得が不要 技術的課題： ランタイムの二重実行による性能への悪影響 ランタイムのWasm化でランタイム・実行最適化中立 線形メモリ スタック プログラム カウンタ 0x00 0xff 任意のホストWasmランタイム セルフホストWasmインタプリタ ライブマイグレーション機構 Wasmバイトコード 線形メモリ スタック プログラム カウンタ 0x00 0xff 

11 セルフホスト環境と通常実行環境でのアプリケーション性能差 • セルフホスト化Wasm3でベンチマークを実行[3] • セルフホストをサポート、高速インタプリタ方式 • Wasm3、Wasmtime(JITコンパイル)での直接実行と比較 アプリケーション実行にかかる時間が大幅に増加 [3]DaIsaac Gouy. mandelbrot rust #4 program (benchmarks game). https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-rust-4. html. (Accessed on 08/15/2024). 計測対象 実行時間（秒） Wasm3 83.53 セルフホストWasm3 on Wasm3 3125.61 Wasmtime 14.02 セルフホストWasm3 on Wasmtime 1579.32 37倍 112倍 OS Ubuntu 22.04 LTS(Linux 5.15.0) CPU Intel Xeon Silver 4208 メモリ 32 GB 実験環境（さくらの専用サーバPHY RX2530 M5） 

12 既存の内部状態取得コード挿入手法(Wasabi)との性能比較 セルフホストはホストランタイムに合わせて性能が変化 実行時間（分） Wasabi Wasm3 on Wasm3 Wasm3 on Wasmtime Wasm3 on WasmEdge(AOT) Wasm3 on WasmEdge(Interp.) 0 50 100 150 200 250 Wasabiよりも高速な状態取得 高速インタプリタ JIT・AOTコンパイルで性能向上 • WasabiとセルフホストWasm3で線形メモリ状態を取得 • 100万項のライプニッツ級数を用いた円周率計算で メモリアクセスをトラップ • Wasm3、Wasmtime、WasmEdgeで セルフホストWasm３を実行 • Node.jsでWasabiを実行 

13 実行時間（分） Wasabi Wasm3 on Wasm3 Wasm3 on Wasmtime Wasm3 on WasmEdge(AOT) Wasm3 on WasmEdge(Interp.) 0 50 100 150 200 250 既存の内部状態取得コード挿入手法(Wasabi)との性能比較 セルフホストはホストランタイムに合わせて性能が変化 JITコンパイルを用いているが セルフホストより性能が悪化 JavaScript関数の呼び出しによるオーバヘッド • WasabiとセルフホストWasm3で線形メモリ状態を取得 • 100万項のライプニッツ級数を用いた円周率計算で メモリアクセスをトラップ • Wasm3、Wasmtime、WasmEdgeで セルフホストWasm３を実行 • Node.jsでWasabiを実行 

14 実行時間（分） Wasabi Wasm3 on Wasm3 Wasm3 on Wasmtime Wasm3 on WasmEdge(AOT) Wasm3 on WasmEdge(Interp.) 0 50 100 150 200 250 既存の内部状態取得コード挿入手法(Wasabi)との性能比較 セルフホストはホストランタイムに合わせて性能が変化 性能向上のための最適化がない 通常のインタプリタ方式 • WasabiとセルフホストWasm3で線形メモリ状態を取得 • 100万項のライプニッツ級数を用いた円周率計算で メモリアクセスをトラップ • Wasm3、Wasmtime、WasmEdgeで セルフホストWasm３を実行 • Node.jsでWasabiを実行 

15 性能比較まとめと技術的課題に対するアプローチ（ここまでSEC2024の主な内容） • セルフホスト化した既存のWasmランタイムを用いた場合 通常の実行環境に比べて大幅に低下 • Wasabiより良い内部状態取得性能 • 使用するランタイムに合わせてセルフホスト型ランタイムの性能も変化 セルフホストを前提としたWasmインタプリタの最適化によって 性能オーバヘッドを最小限に抑える必要 既存手法より高速だが セルフホストなし場合に比べて大幅に性能が低下 

16 技術的課題の要因 計測対象 総命令数 Wasm3 400,849,582,525 Wasm3 on Wasm3 318,276,978,517,504 794倍増加 Wasm3 Wasm3 on Wasm3 1 op_SetSlot_f64 (28.22%) op_CopySlot_32(16.57%) 2 op_f64_Add_rs(22.15%) op_i32_Load_i32_s(15.51%) 3 op_f64_Multiply_rs(21.53%) op_CallIndirect(8.71%) 4 op_f64_Multiply_ss(7.22%) op_SetSlot_i32(8.36%) 5 op_f64_Subtract_rs(6.41%) op_Entry(6.89%) 要因2. 算術演算より線形メモリ・制御命令処理が増加 これらの命令処理に関する高速化が必要 要因1. 必要な命令が大幅に増加 セルフホストインタプリタの 命令数削減が必要 Wasabiとの比較に使用したベンチマークにおける処理内容の差 

17 要因1を解決するインタプリタ最適化の既存手法：メタトレーシング（Pypy）[4] • インタプリタをトレースし 最適化されたネイティブバイナリを生成 • インタプリタのループを展開し ユーザプログラム実行時のホットパスを抽出 • インタプリタの作者はどこからトレースをはじめるか ヒント情報を与える • 各ランタイムにトレース機構を実装する必要 • 多様なランタイムへの対応が難しい 最適なインタプリタを生成できるが、ホストランタイムに制約 [4]Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski, and Armin Rigo. 2009. Tracing the meta-level: PyPy's tracing JIT compiler. In Proceedings of the 4th workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages and Programming Systems (ICOOOLPS '09). Association for Computing Machinery, New York, NY, USA, 18–25. https://doi.org/10.1145/1565824.1565827 メタトレーシングの概念図 (https://pypy.org/posts/2018/09/the-first-15-years-of-pypy- 3412615975376972020.html) 

18 要因1を解決するインタプリタ最適化の既存手法： 自己最適化（Truffle・Graal VM）[5] • Truffle: 実行中の値に合わせ自身を最適化するASTインタプリタのフレームワーク • Wasmは型が静的に決まるため主に値の定数化とキャッシュ、分岐予測、ホットパスのコード生成 • Graal VM：Truffleが生成したASTから汎用性を落として更に最適化 • 任意のランタイムへの適用は 難しい • Graal VMに依存 高速なセルフホストインタプリタだが、特定のVM実装に依存 [5]Salim S. Salim, Andy Nisbet, and Mikel Luján. 2020. TruffleWasm: a WebAssembly interpreter on GraalVM. In Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE '20). Association for Computing Machinery, New York, NY, USA, 88–100. https://doi.org/10.1145/3381052.3381325 

19 セルフホストインタプリタだけで完結する最適化アプローチの検討 • 命令処理のWasmインライン化による命令単位の最適化 • 内部状態を取得しながらも、セルフホストインタプリタ内の処理を削減可能 • セルフホストインタプリタ解釈はするが命令処理しない • 実際の命令処理をホストランタイムにパスし、直接評価させるため WasmランタイムでWasmインタプリタを実行することに着目 while (1) { opc = *ip++; switch (op) { case Call_Indirect: { idx = stack.pop(); /*Lots of processing…*/ } } } … case Call_Indirect: { idx = stack.pop(); wasm!( I32Const #{idx} call_indirect ) … Wasmバイトコード生成の概念 

20 要因2：線形メモリや制御命令処理増加による影響 • サンドボックス： 悪意のあるプログラムから実行環境を保護 • 実行前：バイトコード検証と 実行中：スタック・線形メモリの保護 • 既知の実行時性能のオーバヘッド[6,7] • メモリに関する処理が増加した結果 • 境界値チェック処理にかかる時間も増大 二重サンドボックスによる処理時間増大 セルフホストWasmランタイム ホストWasmランタイム サンドボックス 0x00 0xff サンドボックス(セルフホスト) 型の一致や 命令の有効性を検証 0x00 0xff 型の一致や 命令の有効性を検証 境界値チェック [6]Matthew Kolosick, Shravan Narayan, Evan Johnson, Conrad Watt, Michael LeMay, Deepak Garg, Ranjit Jhala, and Deian Stefan. Isolation without taxation: near-zero-cost transitions for webassembly and sfi. Proc. ACM Program. Lang., Vol. 6, No. POPL, jan 2022. [7]Raven Szewczyk, Kimberley Stonehouse, Antonio Barbalace, and Tom Spink. Leaps and bounds: Analyzing webassembly ’s performance with a fo- cus on bounds checking. In 2022 IEEE Interna- tional Symposium on Workload Characterization (IISWC), pp. 256–268, 2022. 

21 要因2を解決するアプローチの検討 • ホストWasmランタイムのみ サンドボックスを作成 • 二重処理を排除 • ホストWasmランタイムの サンドボックス機構を活用して 安全性を維持 セルフホストインタプリタのサンドボックス機構の削減 セルフホストWasmランタイム ホストWasmランタイム サンドボックス 0x00 0xff 0x00 0xff 

22 セルフホストインタプリタ実装状況 • インタプリタ処理最適化 • 現在実装に向けて絶賛検証中 • さらなる高速化のアイデア：ホットパス命令列の動的Wasmバイトコード生成 • 実行頻度が高い命令列をWasmバイトコード化し、ホストランタイムにパススルー • マイグレーション時はセルフホストインタプリタにフォールバック（脱最適化） • 二重サンドボックスの削減 • サンドボックスを排除した最小構成のセルフホストインタプリタを実装し、絶賛性能評価中 • 次回作（発表・論文）にご期待ください 

23 まとめ • ランタイム実装やバイトコード実行最適化に非依存な ライブマイグレーション機構の実現 • セルフホストインタプリタによるWasmマイグレーション手法 • ライブマイグレーション機構を備えたWasmインタプリタをセルフホスト化することで ランタイム・最適化手法に依存した内部状態取得が不要 • 既存のランタイムのセルフホスト化は、 既存手法より高速だがアプリケーション性能が大幅に低下 • 実行に必要な命令が大幅に増加 • 二重サンドボックスによる実行時性能低下 • 動的なWasmバイトコード生成とサンドボックス処理の排除による性能向上を目指して セルフホストインタプリタを実装中