中田 裕貴（さくらインターネット株式会社/公立はこだて未来大学） 松原 克弥（公立はこだて未来大学） JIT/AOTコード最適化と両立する WebAssemblyライブマイグレーション実現手法の検討 2025/5/22 情報処理学会 第167回システムソフトウェアとオペレーティング・システム研究発表会 

2 エッジコンピューティングにおける分散処理 • エッジサーバ：ユーザやデバイス近傍への配置による低通信遅延 • クラウドサーバ：高性能なGPUやストレージを活用 特性が異なる計算機を組み合わせ、それらを活かした連携 大 小 処理能力・通信遅延 クラウド エッジ デバイス 高負荷なタスクのオフロード 移動に追従するハンドオフ 

3 実現に必要なアプリケーション実行環境の特性 1. アーキテクチャ中立性 • クラウド環境ではx86_64、デバイス環境では省電力なARMが普及 [1] • アーキテクチャの差異を吸収可能な実行環境が必要 2. 高効率なアプリケーション実行 • 各計算機特性は異なり、それぞれに最適化された環境が必要 • e.g., ハードウェア性能や構成、電力制約など 3. 可搬性 • オフロードやハンドオフには、アプリケーションと実行状態を 共に移動するライブマイグレーションが必要不可欠 [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. 内部実行状態 

4 WebAssembly（Wasm） 多様な計算機環境でアプリケーションを高効率に実行 クラウドやエッジ・デバイス向けなど 特定環境に特化したランタイム実装 仮想命令セットアーキテクチャ … Wasmバイトコード あらゆる言語から コンパイル Rust C言語 デバイス向けランタイム e.g., WAMR (WebAssembly Micro Runtime) デバイス環境 (ARM) クラウド環境 (x86_64) クラウドネイティブ向けランタイム e.g., WasmEdge Wasmバイトコード Wasmバイトコード 低メモリ消費・ 電力消費 高速実行 

5 Wasmにおける内部実行状態の保存と復元 プログラムカウンタ … Local.get Local.get I32.add … 0xaaa 0xbbb 次に実行する命令のアドレス 0xabb 線形メモリ H e l l o \n 0x00 0x05 配列や文字列などを格納 スタック 2 1 … 値スタック Int a = 1 + 2; … フレームスタック Args: … RetAddr: … Locals:… ランタイムが作成するVMの状態が必要 

6 異種プラットフォーム間Wasmライブマイグレーション ランタイム実装と性能最適化に内部実行状態が依存 仕様化されているが実現方法は多様 ランタイムの性能最適化(JIT/AOTコンパイル)で ランタイムのVM外に散在 プログラム カウンタ フレーム スタック 値スタック OSスタック Wasm VM 線形メモリ プログラム カウンタ フレーム スタック 32bit表現 値スタック Wasm VM(ランタイムA) 線形メモリ Wasm VM(ランタイムB) ≠ プログラム カウンタ プログラム カウンタ 0xFFFFFFFF 64bit表現 値スタック 0xFFFFFFFF FFFFFFFF 線形メモリ フレーム スタック Locals:… module:… Locals:… module:… Internal:… 

7 既存のWasm内部実行状態保存・復元手法 実行性能や異種ランタイム・性能最適化方式対応に課題 Wasmランタイム内での保存・復元[2] コード 挿入 内部状態分析 外部関数 … 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 … ランタイムごとに独自の実装が必要 状態変換が複雑化 ネイティブコンパイル時の命令挿入[4] 特定のコンパイラ基盤と 実行方式に依存 バイトコードの事前改変[3] 外部の分析関数を呼び出すことで オーバヘッドが増大 ランタイムA Wasmバイトコード 内部実行状態保存・復元 for A ランタイムB Wasmバイトコード 内部実行状態保存・復元 for B [2] D. Fujii, K. Matsubara, and Y. Nakata, “Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations”, Proceedings of the 7th International Workshop on Edge Systems, Analytics and Networking, pp. 19–24, Apr. 2024, doi: https://doi.org/10.1145/3642968.3654816. [3] D. Lehmann and M. Pradel, “Wasabi: A framework for dynamically analyzing webassembly”, Architectural Support for Programming Languages and Operating Systems, Apr. 2019, doi: https://doi.org/10.1145/3297858.3304068 [4] Y. Yang, A. Hu, Y. Zheng, B. Zhao, X. Zhang, and A. Quinn, “Transparent and Efficient Live Migration across Heterogeneous Hosts with Wharf”, arXiv (Cornell University), Oct. 2024, doi: https://doi.org/10.48550/arXiv.2410.15894 マイグレーション可能 ネイティブバイナリ コンパイル時 に挿入 ライブマイグレーション用 命令（中間表現） 

8 提案：セルフホストWasmランタイムによるライブマイグレーション 線形メモリ スタック プログラム カウンタ 0x00 0xff 任意のホストWasmランタイム セルフホストWasmランタイム 内部実行状態保存・復元機構 Wasmバイトコード 線形メモリ スタック プログラム カウンタ 0x00 0xff セルフホストの 内部実行状態のみ利用 • 内部実行状態保存・復元機構を備えた WasmランタイムをWasmにコンパイル • セルフホストランタイムを介した アプリケーション実行 • 既存のWasmランタイムの改変が不要 • ホストランタイムの JIT/AOTコンパイル最適化に非依存 • ライブマイグレーションに セルフホストランタイムの内部実行状態のみ使用 

9 提案手法における考慮事項 セルフホストランタイムによる性能低下 • セルフホストランタイムを用いることで 二重のランタイム処理が発生するため • 研究課題１：性能低下の把握と要因の特定 • 研究課題２： セルフホストランタイムに特化した性能最適化手法 

10 性能低下の把握と要因の特定 • 既存のWasmランタイムをセルフホスト化し数値演算処理のベンチマークを実行[5] • Wasm3：セルフホストに対応したインタプリタ方式のランタイム • ホストランタイム：Wasm3、Wasmtime（JITコンパイル方式） ホストランタイムの性能最適化を活用しても性能が大幅に低下 計測対象 実行時間（秒） Wasm3 83.53 セルフホストWasm3 on Wasm3 3125.61 Wasmtime 14.02 セルフホストWasm3 on Wasmtime 1579.32 37倍 112倍 ベンチマーク実行結果[5] [5] Y. Nakata and K. Matsubara, “Poster: Feasibility of Runtime-Neutral Wasm Instrumentation for Edge-Cloud Workload Handover”, pp. 528–530, Dec. 2024, doi: https://doi.org/10.1109/sec62691.2024.00068. 

11 性能低下の要因１：複雑なランタイム処理の重複 • サンドボックス： 悪意のあるプログラムから実行環境を保護 • 既知の実行時性能のオーバヘッド[6,7] • ホスト・セルフホストランタイムの 双方で実行 [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. サンドボックス 型の一致や 命令の有効性を検証 0x00 0xff 実行中の 境界値チェックなど アプリケーションの バイトコード 

12 性能低下の要因１：複雑なランタイム処理の重複 • サンドボックス： 悪意のあるプログラムから実行環境を保護 • 既知の実行時性能のオーバヘッド[6,7] • ホスト・セルフホストランタイムの 双方で実行 サンドボックス 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. 

13 性能低下の要因２：ホストランタイムで処理する命令が大幅に増加 計測対象 ベンチマーク時の総命令数 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%) 数値演算からメモリ・スタック命令など より高負荷な処理への変化 • ホストランタイムは Wasmバイトコード化されたセルフホストランタイムの命令処理を実行する必要 • ホストランタイムで実行する命令の傾向も変化 • 要因１のサンドボックス処理が必要な命令の呼び出しも増加 

14 研究課題２：セルフホストランタイムに特化した性能最適化手法 • 研究課題1の調査結果から 既存のランタイムのセルフホスト化は著しい性能低下 • セルフホスト化されることを前提とした性能最適化が実装されたランタイムが必要 • 本研究の最適化アプローチ 1. サンドボックス機構の削減 2. セルフホストでの命令処理の簡略化 3. ホットスポットのオフローディング 4. バイトコード合成 • 高度な最適化の代わりに ライブマイグレーションやアプリケーションに制約 • 現在検討中 • 制約無しで実現可能 • 実装済 

15 アプローチ１：サンドボックス機構の削減 • セルフホストランタイムでサンドボックスを 作成しないことで二重処理を排除 • ホストランタイムのサンドボックスで 安全性を維持 • セルフホストランタイムの命令処理は サンドボックス内で実行 ホストランタイムのサンドボックスのみ活用 サンドボックス 0x00 0xff セルフホストランタイムの バイトコード アプリケーションの バイトコード セルフホストランタイム のサンドボックス 0x00 0xff ホストランタイムの サンドボックスのみ使用 

16 アプローチ２：セルフホストでの命令処理の簡略化 • 通常のランタイムと同様に実装した場合、単一の命令が複数の命令に変化 • インラインWasmコードで処理対象の命令に置き換え ホストランタイムに命令実行をパススルー • Wasmにコンパイルする特性を活用 処理対象の命令を用いて命令処理を実装 fn f64_nearest(…) -> …{ let x = value_stack.pop(); let y = x.fract(); let result = if y == 0.5 { x.floor() } else if y == -0.5 { x.ceil() } else { x.round() }; … } fn f64_nearest(…) -> …{ let x = value_stack.pop(); asm!( "local.get {0}", "f64.nearest", "local.set {1}", in(local) x, out(local) result, ); … } 

17 アプローチ３：ホットスポットのオフローディング 頻繁に実行する処理をホストランタイムで直接実行 • Wasmバイトコードのトレーシング機構を実装 • ホットスポットを検出しホストランタイムへオフロード • ホットスポットの二重処理をスキップ • オフロード中の ライブマイグレーションに制約 • 内部実行状態がホストランタイムに存在 • オフロードの前後でのみ ライブマイグレーションを許可 ホストWasmランタイム セルフホスト Wasmランタイム トレーシング機構 Wasmバイトコード 頻繁に実行される 関数・ブロックを特定 ホストランタイムへ オフロード 

18 アプローチ４：バイトコードの合成 単一のバイトコード化によるホストランタイムJIT・AOTの適用 • 現実装はホストのJIT・AOTコンパイルを活用できない • 実行対象のバイトコード命令を逐次実行するため ホストランタイムからバイトコードを認識できない • ランタイムとアプリケーションを 単一バイトコードに合成、ホストで実行 • バイトコードの事前改変が必要 • ライブマイグレーション可能な命令を ランタイム内の命令ハンドラへの関数呼び出しに書き換え … local.get $p1 local.get $p2 i32.add call $hoge … アプリケーションの バイトコード ランタイム機能の バイトコード … local.get $p1 local.get $p2 call $handle_add call $handle_call … … func( $add … func( $call … … func( $handle_add … func( $handle_call … 合成済み バイトコード 

19 アプローチ１・２に関するアプリケーション性能計測 • 比較対象 • ホストランタイムで直接実行、セルフホストWasm3、 提案手法（サンドボックス削減）、 提案手法（サンドボックス削減＋インライン）、既存のバイトコード改変手法（Wasabi） • ベンチマークプログラム • 10万項のライプニッツ級数を用いた円周率計算 • ホストランタイム • Wasm3（インタプリタ）、Wasmtime（JITコンパイル）、 WasmEdge（インタプリタ/AOTコンパイル） • Wasabiの実行にはNode.js（JITコンパイル）を使用 制約無しで実現可能な最適化アプローチの有効性を評価 OS Ubuntu 22.04.4 LTS(Linux 5.15.0) CPU Intel Xeon Silver 4208 8Core 2.10GHz メモリ 32 GB ストレージ SSD 480GBx2 (RAID1) 実験環境 （さくらの専用サーバPHY RX2530 M5 8コア 1CPU） 

20 アプリケーション性能の計測結果 直接実行 セルフホスト Wasm3 提案実装 サンドボックス削減 提案実装 サンドボックス削減 ＋インライン化 Wasabi Wasmtime 0.008 0.101 0.098 0.108 N/A Wasm3 0.011 1.762 0.300 0.316 N/A WasmEdge 0.375 46.785 4.875 5.299 N/A WasmEdge (AOT) 0.041 0.555 0.119 0.124 N/A Node.js N/A N/A N/A N/A 912.641 ベンチマーク実行にかかった時間（秒） 

21 アプリケーション性能の計測結果 直接実行 セルフホスト Wasm3 提案実装 サンドボックス削減 提案実装 サンドボックス削減 ＋インライン化 Wasabi Wasmtime 0.008 0.101 0.098 0.108 N/A Wasm3 0.011 1.762 0.300 0.316 N/A WasmEdge 0.375 46.785 4.875 5.299 N/A WasmEdge (AOT) 0.041 0.555 0.119 0.124 N/A Node.js N/A N/A N/A N/A 912.641 ベンチマーク実行にかかった時間（秒） 直接実行に比べて 2.9〜27倍実行時間を要した 

22 アプリケーション性能の計測結果 直接実行 セルフホスト Wasm3 提案実装 サンドボックス削減 提案実装 サンドボックスなし ＋インライン化 Wasabi Wasmtime 0.008 0.101 0.098 0.108 N/A Wasm3 0.011 1.762 0.300 0.316 N/A WasmEdge 0.375 46.785 4.875 5.299 N/A WasmEdge (AOT) 0.041 0.555 0.119 0.124 N/A Node.js N/A N/A N/A N/A 912.641 ベンチマーク実行にかかった時間（秒） 実行にかかる時間を 約2.9〜89.5％削減 特にインタプリタ方式の ホストランタイムで大幅な削減 

23 アプリケーション性能の計測結果 直接実行 セルフホスト Wasm3 提案実装 サンドボックス削減 提案実装 サンドボックス削減 ＋インライン化 Wasabi Wasmtime 0.008 0.101 0.098 0.108 N/A Wasm3 0.011 1.762 0.300 0.316 N/A WasmEdge 0.375 46.785 4.875 5.299 N/A WasmEdge (AOT) 0.041 0.555 0.119 0.124 N/A Node.js N/A N/A N/A N/A 912.641 ベンチマーク実行にかかった時間（秒） 実行にかかる時間を 大幅に削減 

24 アプリケーション性能の計測結果 直接実行 セルフホスト Wasm3 提案実装 サンドボックス削減 提案実装 サンドボックス削減 ＋インライン化 Wasabi Wasmtime 0.008 0.101 0.098 0.108 N/A Wasm3 0.011 1.762 0.300 0.316 N/A WasmEdge 0.375 46.785 4.875 5.299 N/A WasmEdge (AOT) 0.041 0.555 0.119 0.124 N/A Node.js N/A N/A N/A N/A 912.641 ベンチマーク実行にかかった時間（秒） インライン化によって 性能が悪化 

25 実験結果のまとめと考察 既存手法より高速だが直接実行した場合より性能が大幅に低下 • 提案手法は既存ランタイムのセルフホスト化より性能が向上 • ホストランタイムがインタプリタ方式の場合、大きく改善 • 多くの命令で実行されるサンドボックス処理を軽減されたため（アプローチ１） • インライン化による命令数削減は効果がなかった（アプローチ２） • 実行状態取得のために命令前後で引数と戻り値のpush/pop命令の発生と コンパイラ最適化の阻害が要因であると推測 • 最適化アプローチ３・４のようなより高度な最適化が必要不可欠 

26 まとめ • セルフホストに特化したWasmランタイムによる 異種ランタイム・性能最適化方式間ライブマイグレーションを提案 • セルフホストWasmランタイムの内部実行状態を活用してランタイムや性能最適化方式に非依存 • セルフホスト化されることを前提とした性能最適化が必要不可欠 • 既存手法よりアプリケーション実行性能は高速であるが直接実行より大幅に低下 • サンドボックス機構の削減は有効であったが、命令処理の簡略化の効果はなかった • 今後はより高度な最適化アプローチについて検討・実装を進める • ホットスポットのオフローディング・バイトコードの合成