日本ソフトウェア科学会第 41 回大会 (2024 年度) 講演論文集

セルフホスト型ランタイムによる WebAssembly
インストルメンテーションの実現可能性検討
中田 裕貴

松原 克弥

クラウドコンピューティング基盤に欠かせない機能のひとつである VM マイグレーションの実現には，VM や VM
内で稼働するアプリケーションの実行状態を任意のタイミングで抽出・復元する技術が必要不可欠である．本研究では，エッジ・クラウドコンピューティング向けシステム基盤としての活用が注目されている WebAssembly を対象として，VM マイグレーションに最適なバイナリインストルメンテーション機能の実現手法として，セルフホスト型
ランタイムに着目した．多種多様なランタイムが現存し，ネイティブコンパイル等の最適化技術が適用されることも多い WebAssembly アプリケーションの実行状態抽出には，ランタイム中立性と実行時性能を両立できるバイナリ
インストルメンテーションが求められる．本稿では，WebAssembly アプリケーションの実行状態を取得するためのインストルメンテーション機能を備えたセルフホスト型ランタイムについて，既存インストルメンテーション手法との比較や予備実験による評価により，その実現可能性を検討する．

Wasm） [1] を用いたエッジコンピューティング環境

1 はじめににおける VM マイグレーションの実現に有用である

バイナリインストルメンテーション (Binary In-と考えている．VM マイグレーションは，あるマシン

strumentation) は，アプリケーションの実行状態をで実行中のアプリケーションを実行状態と共に別マシ

観察するための技術である．変数やメモリの値，リンに移し，処理を途中から再開させる技術である．ア

ソース使用量，各命令の実行回数などの統計情報を取プリケーション実行ランタイムでのインストルメント

得するコードや機能をアプリケーションに加えるこ

コードの動的挿入を用いて，アプリケーションの内部とで，バグの追跡やフローの可視化，プロファイリン

状態を取得と移行先ランタイムでの内部状態の復元をグ，リアルタイム監視などを実現する．バイナリイン行うことで，VM マイグレーションを実現できる．対ストルメンテーションは，アプリケーション実行前にして，静的挿入は，インストルメントコードの呼び出

バイナリへインストルメントコードを静的に挿入すしによってアプリケーション性能も低下する [2] だける手法と，アプリケーション実行中にランタイム内でではなく，実行状態の復元や特定の内部状態に関する

動的に挿入する手法がある．

インストルメンテーションが難しく，VM マイグレー

著者らは，インストルメントコードの動的挿入に

ションには適さない．エッジコンピューティングは，

よるバイナリインストルメンテーションが，仮想命令

ユーザ近傍に存在するコンピューティングリソースを

セットアーキテクチャである WebAssembly（以下，活用し，デバイス環境とエッジ環境，クラウド環境など多様な CPU アーキテクチャのコンピューティング

Feasibility Study of WebAssembly Binary Instrumentation with Self-hosted Runtime
Yuki Nakata, 公立はこだて未来大学/さくらインターネッ
ト株式会社, Future University Hakodate/SAKURA
internet Inc..
Katsuya Matsubara, 公 立 は こ だ て 未 来 大 学, Future
University Hakodate.

環境が連携する分散処理環境を実現する [3] [4]．このような環境では，計算性能が要求される処理のクラウドへのオフローディングや，アプリケーションユーザ
の移動 [5] に合わせた処理のハンドオフに VM マイグ
レーションを活用することで，アプリケーションの可用性を向上できる [6] [7] [8] [9]．エッジコンピューティ

るランタイム・実行方式非依存なバイナリインストル

ングは，各環境で使用される CPU アーキテクチャがメンテーションの有用性と実現可能性を明らかにする

異なるため [10]，あらゆるプログラミング言語で記述

ために，Wasm における既存のインストルメンテー

されたプログラムを Wasm バイトコードにコンパイション手法を整理し，それらの課題を明らかにする．

ルし，多様な CPU アーキテクチャ上でバイトコード

そして，セルフホスト化した既存の Wasm ランタイを実行できる VM を作成する Wasm が有用である．

ムと既存の静的なインストルメントコード挿入手法

また，Wasm ランタイムは，デバイスやクラウド環

で実行時性能を評価し，動的なインストルメントコー

境など，それぞれに特化したランタイム実装が数多く

ド挿入手法とセルフホスト化した Wasm ランタイム

存在するため，エッジコンピューティングにおける，の利点と課題を明らかにする．明らかにした課題をもアプリケーションのオフローディングやハンドオフをとに，セルフホスト化を前提とした Wasm ランタイ

シームレスに実行できる [11]．

ムの設計方針について議論する．

しかしながら，Wasm におけるインストルメント
コードの動的挿入は，多様な Wasm ランタイムの存

2 既存手法とその課題

在やランタイムごとのアプリケーション実行方式のWasm バイトコードへのインストルメンテーショ

差異によって実現が難しい．Wasm は，バイトコーン手法は，静的なインストルメントコード挿入手法，

ドや仮想マシンの標準仕様があるが，仕様を実現す

ランタイム内での動的なインストルメントコード挿る実装はランタイムによって多様である．そのため，入手法と，ランタイム外でのインストルメンテーショ

複数のランタイムを用いた環境では，各ランタイムにン手法がある．これらの手法は，アプリケーション性

バイナリインストルメンテーション機能を実装する必能やインストルメンテーション機構実装の複雑さ，正要がある．また，Wasm ランタイムは，バイトコー

確な内部状態の取得においてトレードオフがある．

ドを逐次解釈するインタプリタ方式や，バイトコードを実行中にネイティブバイナリへコンパイルする

2. 1 静的なインストルメントコード挿入手法

JIT（Just-In-Time）方式，実行前にコンパイルする

Wasabi [12] は，Wasm バイトコード実行前にイン

AOT（Ahead-Of-Time）方式など多様な実行方式がストルメントコードを挿入することで，Wasm アプ

存在する．実行方式によってアプリケーションが使用

リケーション内状態の取得と複雑な解析を実現してする Wasm 仮想マシン内リソースや実メモリ・CPU

いる．インストルメントコードは，命令単位や，関数などのリソース使用特性が変化するため，バイナリイ

呼び出し前・呼び出し後などあらゆる場所に挿入さンストルメンテーション機構も実行方式を意識して実れるため，アプリケーションの状態を詳細に把握で装しなければならない．

きる．バイトコードを改変して状態収集を実現する

本研究は，セルフホスト型 Wasm ランタイムによため，AOT や JIT などの実行方式の違いによる影響

るランタイム・実行方式に非依存な動的なバイナリイは受けない．Wasabi は，複雑な解析を実現するため

ンストルメンテーション機構を提案する．バイナリイに，バイトコードに挿入されるインストルメントコー

ンストルメンテーション機構が実装された Wasm ラ

ドは解析処理を含んでおらず，JavaScript で記述さンタイムを Wasm にセルフホストコンパイルし，あれた解析用関数を呼び出す．高水準言語の機能を用いらゆる Wasm ランタイム上でセルフホスト Wasm ラて解析関数を記述することで，単純な命令数のカウン

ンタイムを用いてアプリケーションを実行する．セル

トのみならず，コールグラフの作成，メモリアクセス

フホスト型 Wasm ランタイムによって各ランタイムの追跡などを容易に実現できる．また，プログラムのへのインストルメンテーション機構の実装とネイティ

元の挙動に対する悪影響を軽減するために，挿入されブ環境における実行方式を意識する必要がなくなる．

たインストルメントコードはデータフローや制御フ

本稿では，セルフホスト型 Wasm ランタイムによローを改変せず，挿入前のバイトコードと同等の振る舞いを維持する．

サポートしているため，実行方式ごとに異なるインス

しかしながら，Wasabi はあらゆる命令の前後に

トルメンテーション機構を実装している．Wizard とインストルメントコードを挿入し，状態取得用の同様のアプローチを用いた場合，ランタイムとその実

JavaScript 関数呼び出しが大量に発生するため，ア

行方式を考慮したインストルメンテーション機構を複プリケーション性能が大幅に低下する．また，アプリ

数実装する必要がある．

ケーションの規模や，取得したい内部状態の粒度に応じてバイトコードのサイズも肥大化する．

Observe SDK [13] は，Wasabi と同様にバイトコー

2. 3 ランタイム外でのインストルメンテーション
手法

ドへのインストルメントコードの挿入と，Wasm へ

Dtrace [14] は，アプリケーションや OS カーネルな

コンパイルする前のアプリケーションコードにインス

ど，システム全体のあらゆる状態をリアルタイムに収トルメントコードを追加する手段を提供する．また，集できる．アプリケーションに対して動的にインスト

インストルメントコードと既存のモニタリングツー

ルメンテーションできるため，アプリケーションやバルを連携させることで，内部状態を可視化し，アプリ

イナリの改変は不要である．Dtrace は，OS カーネル

ケーションの状態を詳細に把握できる．しかしながの機能として動作するため，アプリケーション性能にら，バイトコードへのインストルメントコードの挿入

与えるオーバヘッドを最小限に抑えることもできる．

は Wasabi と同様の課題がある．また，コンパイル前

Dtrace は Wasm ランタイム外からインストルメンのアプリケーションコードにインストルメントコード

テーションを行うため，取得可能なアプリケーショを追加することは，アプリケーション実装に使用可能

ン内部状態に制約がある．Dtrace で取得できる内部なプログラミング言語の制約を発生させる．

状態の粒度は，プロセスやスレッド単位であるため，

Wasm にコンパイルされたアプリケーションに対し
2. 2 ランタイム内での動的なインストルメント
コード挿入手法て Dtrace を使用した場合，内部状態には Wasm ランタイムが使用したものも含まれている．ランタイム

Wizard [2] は，Wasm ランタイム内で実行中のバイ

外部から取得した内部状態からランタイム状態とアプ

トコードにインストルメントコードを挿入すること

リケーション状態を分類するには，ランタイムの設計で，インストルメンテーションによるオーバヘッドをや実装を完全に把握する必要があり，アプリケーショ

最小限に抑えている．Wasabi と異なり，収集したい

ンの内部状態のみを正確に取得するのは難しい．

状態に関わる命令の前後にインストルメントコードを挿入するのではなく，対象の命令をインストルメン

3 提案手法トコードに置き換える．インストルメントコードの挿

本研究は，セルフホスト型 Wasm ランタイムによ入と抜去は動的に動的に実行され，インストルメント

るランタイム・実行方式非依存な動的なバイナリイ

コードが挿入されていない場合は通常の Wasm バイ

ンストルメンテーション機構を提案する．図 1 のよトコード実行であり，実行性能に与えるオーバヘッド

うに，バイナリインストルメンテーション機構実装を大幅に削減できる．また，ランタイムにインストル

した Wasm ランタイムを Wasm にセルフホストコン

メンテーション機構が実装されているため，ランタイ

パイルし，あらゆる Wasm ランタイム上でセルフホムが管理しているスタックやメモリに関する状態にもスト Wasm ランタイムを用いてアプリケーションをアクセス可能であり，より多くの状態を収集できる．

実行する．セルフホスト化するランタイムにのみイ

しかしながら，ランタイムを拡張して実装されてンストルメンテーション機構を実装し，既存のあらいるため，多様な Wasm ランタイムを組み合わせた

ゆる Wasm ランタイム上で実行すればよいため，各

環境における状態収集には課題がある．Wizard のランタイムの実装に合わせたインストルメンテーショ

Wasm エンジンは，インタプリタ方式と JIT 方式をン機構が不要にする．JIT・AOT コンパイルはセル表10

アプリケーションのWasmバイトコード

1

OS

Ubuntu 22.04.4 LTS(Linux 5.15.0)

CPUIntel(R) Xeon(R) Silver 4208 8Core 2.10GHz

メモリ

32 GB

線形メモリ

スタック

インストル
メンテーション機構

実験に使用したマシンの仕様

プログラム
カウンタ

ストレージ

状態取得・分析SSD 480GBx2 (RAID1)

セルフホスト型Wasmランタイム

コードをネイティブバイナリに AOT コンパイルでき
0
セルフホスト型WasmランタイムのWasmバイトコード

1
線形メモリ

対応している．

スタック

プログラム
カウンタ
Wasmランタイム

図1

る．また，WasmEdge はインタプリタでも実行にもセルフホスト型 Wasm ランタイムによる動的インストルメンテーション

実験環境には，さくらの専用サーバ PHY RX2530

M5 8 コア 1CPU を使用した．使用したマシンの詳細な仕様は表 1 に示す．使用した Wasm ランタ
イムのバージョンは，Wasm3 は v0.5.0，Wastime
は 22.0.0 (9f695788a 2024-06-04)，WasmEdge はフホスト型 Wasm ランタイムに対して適用されるた

0.14.0-48-gd50c269c であった．

め，セルフホスト型 Wasm ランタイム内のインスト
ルメンテーション機構は，これらの実行方式の考慮が4. 1 状態収集に関する性能評価不要となる．また，既存の静的なインストルメント

Wasm バイトコードへの静的なインストルメント

コードの挿入手法は，アプリケーションの大規模化に

コード挿入手法である Wasabi と，セルフホスト化し合わせてバイトコードのサイズも増大するが，セルフた Wasm3 の双方でインストルメンテーションを実施

Wasm ランタイムのバイトコードサイズは一定であしながらベンチマークプログラムを実行し，完了するるため，インストルメンテーションによるバイトコー

までの時間を計測した．内部状態の分析では，ベンチ

ドサイズの増大を軽減できる．

マークのメモリアクセス命令を解析し，使用したメモ
リのページサイズの合計を計算した．ベンチマーク

4 セルフホスト型 Wasm ランタイムの予備評価
既存の Wasm ランタイムをセルフホスト化し，セプログラムは，100 万項のライプニッツ級数を用いた円周率計算を使用した．Wasm3 は，このようなインストルメンテーション機構が実装されていないため，

ルフホスト型 Wasm ランタイムがアプリケーション

Wasm3 の内部状態を用いて同等の分析を行う機能を性能に与えるオーバヘッドを評価した．既存の Wasm

実装し，実行時間を計測した．

ランタイム上でセルフホスト化したランタイムを用

Wasabi は 2024 年 8 月 5 日時点での GitHub 上のいてベンチマークプログラムを実行することで，セル最新版（コミットハッシュ：21a322b7faac）を使用しフホスト型 Wasm ランタイムの性能を計測した．

た．Wasabi の実行には，JavaScript と Wasm の実

セルフホスト化した Wasm ランタイムには Wasm3，

行環境である Node.js 20.16.0 を用いた．

セルフホスト化したランタイムを実行するランタイム

表 2 に示した実験結果から，セルフホスト化したには，Wasm3 と Wasmtime，WasmEdge を使用しWasm ランタイムによるインストルメンテーション

た．Wasm3 はインタプリタ方式のランタイムであり，は，実行時性能に与えるオーバヘッドを既存の静的セルフホストコンパイルに対応している．Wasmtime

なインストルメントコード挿入手法よりも軽減できは，Wasm ランタイムにおける事実上のリファレン

る可能性がある．Wasabi の実行に用いた Node.js のス実装であり，JIT コンパイルによって Wasm バイ

Wasm エンジンは，Wasm バイトコードをネイティ

トコードを実行する．WasmEdge は，Wasm バイト

ブバイナリに JIT コンパイルして実行するが，セル表2

内部状態分析に関する性能

計測対象

実行にかかった時間 (Min.)

Wasabi

25.26

Wasm3 on Wasm3

23.09

Wasm3 on Wasmtime

7.22

Wasm3 on WasmEdge（AOT）

18.02

Wasm3 on WasmEdge（インタプリタ）

208.76フホスト環境と比較して，ベンチマークプログラムのコード処理に関する最適化がされた高速インタプリタ

実行に多くの時間を必要とした．Wasabi の内部状態方式を採用しているためである．これらの結果から，取得・分析関数は，JavaScript で記述され，それらのセルフホスト型 Wasm ランタイムの性能は，実行す関数を呼び出すための命令がベンチマークプログラム

るランタイムの実行特性に依存するといえる．

の Wasm バイトコード内あらゆる箇所に挿入される．
これらの関数呼び出しと Javascript で記述された処

4. 2 セルフホスト化による実行時オーバヘッド

理の実行がベンチマークプログラムの実行性能に与セルフホスト化がアプリケーション性能に課すオーえるオーバヘッドとなっていることが推測できる．対

バヘッドを明らかにするために，Wasm3 と Wasm-

して，セルフホスト環境は，JIT コンパイルを用いた

time 上で直接ベンチマークプログラムを実行した場

Wasmtime や AOT コンパイル時の WasmEdge だけ合と，これらのランタイム上でセルフホスト化したではなく，インタプリタ方式の Wasm3 を用いた場合

Wasm3 を用いてベンチマークプログラムを実行しでも Wasabi より高速であった．セルフホスト化された場合で実行にかかる時間を評価した．ベンチマー

た Wasm3 内にインストルメンテーション機構を実装

クプログラムには，プログラミング言語の性能を評しているため，分析関数をバイトコードから複数回価する The Computer Language24.06 Benchmarks

呼び出す処理を不要にできる．また，ランタイムがバGame に掲載されている，N=16000 でのマンデルブ

イトコードを実行時の Wasm の仮想マシンの状態をロ集合の計算とビットマップ形式での描画プログラム

内部状態として使用できるため，命令そのものの解[15] を使用した．

析による内部状態取得も不要である．この結果から，

表 3 に示した実行時間から，セルフホスト環境はセルフホスト型 Wasm ランタイムは，静的なインス

アプリケーション実行にかかる時間が大幅に増加する

トルメントコード挿入手法と比較して軽量なインスことが判明した．Wasm3 環境では実行にかかる時間

トルメンテーションが可能であるといえる．

が約 3641%，Wasmtime 環境では約 11160%増加しセルフホスト化された Wasm ランタイムは，実際た．Wasm ランタイムは，ベンチマークプログラムに実行する Wasm ランタイムの実行特性を維持したの Wasm 命令に加えて，セルフホスト化した Wasm3

ままインストルメンテーションが可能であることがの命令も解釈・実行する必要があり，実行しなければ判明した．JIT コンパイルする Wasmtime や AOT

ならない処理が増大するためであると推測している．

コンパイルを行う場合の WasmEdge は，セルフホ

また，Wasmtime で用いている JIT コンパイルが適

スト Wasm3 がネイティブバイナリに変化するため，用されるのは，ベンチマークプログラムではなく，セWasm3 やインタプリタの WasmEdge でセルフホス

ルフホスト化した Wasm3 の命令解釈・実行処理のみ

ト Wasm3 を実行する場合よりも性能が向上した．

であるため，ネイティブコンパイルによる最適化がベ

また，同じインタプリタ方式を採用した Wasm3 とンチマークプログラムに対して適用されなくなる．

WasmEdge で実行にかかる時間が大幅に変化したのLinux のパフォーマンス解析ツールである Perf

は，Wasm3 のインタプリタはバイトコード命令のデ[16] を用いて Wasm3 環境の総命令数と呼び出され表3

セルフホスト型 Wasm ランタイムによる実行時間

5 セルフホストに特化した Wasm ランタイ

の変化

ムの検討

計測対象

実行にかかった時間 (Sec.)

Wasm3

83.53

4 章の予備実験の結果から，セルフホスト化される

Wasm3 on Wasm3

3125.61

ことを前提とした Wasm ランタイムを設計する必要

Wasmtime

14.02がある．既存の Wasm ランタイムのセルフホスト化

Wasm3 on Wasmtime

1579.32によるインストルメンテーションは，既存の静的なインストルメントコード挿入手法と比較して軽量なた関数を比較し，セルフホスト化によって増大し内部状態の取得・解析が可能である一方，セルフホ

たオーバヘッドを分析した．Wasm3 で直接ベンチ

スト Wasm ランタイムを使用せずに直接 Wasm プロ

マークプログラムを実行した際の CPU の総命令数グラムを実行した場合に比べ，大幅に性能が低下しは 400,849,582,525 回であり，Wasm3 上でセルフホた．これは，既存の Wasm ランタイムがセルフホス

スト Wasm3 を用いてベンチマークプログラムを実ト化されることを前提とされておらず，セルフホスト

行すると 318,276,978,517,504 回であった．約 4459%

型 Wasm ランタイムと，それを実行するランタイム

命令数が増加しており，ベンチマークプログラムの実

で二重のバイトコード解釈と実行が行われ，実行すべ

行時間と同様な増加であった．

き命令が膨大になることが要因である．

表 4 に示した，ベンチマークプログラム実行中のラ

セルフホストに特化した Wasm ランタイムの設計

ンタイム処理における上位 5 処理から，セルフホスト

として，セルフホスト型 Wasm ランタイムとそれを環境ではランタイムの処理内容が大きく変わることが実行する Wasm ランタイムで二重に実行される機能判明した．Wasm3 で直接ベンチマークプログラムをを削減する．インストルメンテーションに必要最低限実行した場合，単体で最も実行されたのはスタック処なランタイム機能のみをセルフホスト型 Wasm ラン

理（28.22%）であるが，2 位から 5 位までは算術演

タイムに実装することで，実行すべき命令数を削減

算処理であり，これらは全体の 57.31%を占めた．対し，セルフホスト化によるオーバヘッドの削減を目して，Wasm3 上でセルフホスト化した Wasm3 を用

指す．

いてベンチマークプログラムを実行した場合，スタッ

削減可能な機能として，Wasm ランタイムのサン

ク処理は 25.03%，線形メモリ処理が 15.51%，制御

ドボックス機構がある．Wasm ランタイムは，バグや処理が 15.60%であった．直接ベンチマークプログラ

悪意のあるプログラムからユーザや実行環境を保護す

ムを実行した場合と比べ，セルフホスト環境では算術るために，サンドボックス内で Wasm プログラムを演算処理よりも線形メモリと制御に関する処理が大実行する．Wasm のサンドボックスは，実行前の検証

幅に増加した．Wasm は，数値をスタックに格納し，と，Wasm プログラムが使用するスタックや線形メモ

Wasm が配列や構造体など，数値以外の値を線形メ

リをソフトウェアによって分離する Software-based

モリ領域に格納する．ランタイムでのスタック実装にFault Isolation(以下，SFI) によって実現される．実配列を使用していた場合，セルフホスト化によってス

行前の検証は，実行前に未定義関数の呼び出しや型のタック操作も実際に実行されるランタイムでは線形メ

一致，スタック操作などの命令の有効性確認などを確モリ操作に変更されてしまう．加えて，ランタイム内

認する．Wasm における SFI は，線形メモリの境界では解析したバイトコードや内部状態を構造体や配列

値チェック，制御フローの整合性保証，スタックの保に格納する．これらの操作によって線形メモリ処理が護などを実施する．これらの SFI 実装は，アプリケー

増加した．制御処理の増加は，セルフホスト化されたションの Wasm 化した際におけるアプリケーション

Wasm3 のインタプリタ処理が要因であると推測して実行性能の大幅な低下の要因として，広く知られていいる．

る [17] [18] [19] [20]．セルフホスト型 Wasm ランタイム

表4

順位

ベンチマーク実行中におけるランタイム処理の割合

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%)

を用いた場合，セルフホスト環境とそれを実行する

イムの実装を進め，有用性を評価する．また，Wasm

ランタイムで SFI 実装が二重実行されるだけではな

バイトコードの命令解釈・実行処理においてもセルフ

く，4. 2 節で述べたように，メモリ操作に関する命令

ホスト化を前提とした高速化手法の検討を進めたい．

が増加しているため，線形メモリの境界値チェック処理が全体の処理時間の多くを占めることが推測でき

参 考 文 献る．セルフホスト型 Wasm ランタイムにおける SFI[ 1 ] WebAssembly Community Group. Webassembly speciﬁcation ― webassembly 2.0 (draft 2024-0811). https://webassembly.github.io/spec/core/,
2022. (Accessed on 08/12/2024).
[ 2 ] Ben L. Titzer, Elizabeth Gilbert, Bradley
Wei Jie Teo, Yash Anand, Kazuyuki Takayama, andHeather Miller. Flexible non-intrusive dynamic instrumentation for webassembly. In Proceedings ofthe 29th ACM International Conference on Architectural Support for Programming Languages andOperating Systems, Volume 3, ASPLOS ’24, p.
398–415, New York, NY, USA, 2024. Association
for Computing Machinery.
[ 3 ] Keyan Cao, Yefan Liu, Gongjie Meng, and Qimeng Sun. An overview on edge computing research.
IEEE Access, Vol. 8, pp. 85714–85728, 2020.
[ 4 ] Hang Liu, Fahima Eldarrat, Hanen Alqahtani,Alex Reznik, Xavier de Foy, and Yanyong Zhang.
Mobile edge cloud system: Architectures, challenges, and approaches. IEEE Systems Journal,
Vol. 12, No. 3, pp. 2495–2508, 2018.
[ 5 ] Pengcheng Zhang, Yaling Zhang, Hai Dong, andHuiying Jin. Mobility and dependence-aware qosmonitoring in mobile edge computing. IEEE Transactions on Cloud Computing, Vol. 9, No. 3, pp.
1143–1157, 2021.
[ 6 ] Keerthana Govindaraj and Alexander Artemenko. Container live migration for latency criticalindustrial applications on edge computing. In 2018
IEEE 23rd International Conference on Emerging Technologies and Factory Automation (ETFA),
Vol. 1, pp. 83–90, 2018.
[ 7 ] Lele Ma, Shanhe Yi, Nancy Carter, and Qun Li.
Eﬃcient live migration of edge services leveraging
container layered storage. IEEE Transactions on
Mobile Computing, Vol. 18, No. 9, pp. 2020–2033,
2019.
[ 8 ] Wei Lu, Xianyu Meng, and Guanfei Guo. Fast
service migration method based on virtual machine

実装の削減は，セルフホスト環境における Wasm ア
プリケーションの実行性能向上に寄与できる．また，セルフホスト型 Wasm ランタイムを実行するランタ
イムは，境界値チェックなどの SFI をセルフホスト

Wasm ランタイムに対して適用する．そのため，セルフホスト型 Wasm ランタイムとアプリケーション
はサンドボックス内で実行されており，Wasm の安全性は維持できる．

6 おわりに
著者らは，ランタイム・実行方式に非依存なバイナ
リインストルメンテーションを実現するために，セルフホスト型 Wasm ランタイムを提案した．動的なインストルメントコードの挿入は，Wasm を用いた
エッジコンピューティングにおける VM マイグレー
ションに有用であるが，多様な Wasm ランタイムの存在やランタイムごとのアプリケーション実行方式の差異によって実現が難しい．実験の結果，セルフホス
ト型 Wasm ランタイムによるバイナリインストルメ
ンテーションは，既存の静的なインストルメントコー
ド挿入手法より高速であるが，依然として通常の通常実行時より性能が大幅に低下することが判明した．
そこで，二重で実行されるサンドボックス機構の削減によるセルフホストを前提とした Wasm ランタイムの方針を示し，議論した．
今後は，議論したセルフホスト特化型 Wasm ランタ

technology for mec. IEEE Internet of Things Journal, Vol. 6, No. 3, pp. 4344–4354, 2019.
[ 9 ] Daigo Fujii, Katsuya Matsubara, and Yuki
Nakata. Stateful vm migration among heterogeneous webassembly runtimes for eﬃcient edge-cloud
collaborations. In Proceedings of the 7th International Workshop on Edge Systems, Analytics andNetworking, EdgeSys ’24, p. 19–24, New York, NY,
USA, 2024. Association for Computing Machinery.
[10] Li Lin, Xiaofei Liao, Hai Jin, and Peng Li. Computation oﬄoading toward edge computing. Proceedings of the IEEE, Vol. 107, No. 8, pp. 1584–
1607, 2019.
[11] Jämes Ménétrey, Marcelo Pasin, Pascal Felber,and Valerio Schiavoni. Webassembly as a common
layer for the cloud-edge continuum. In Proceedingsof the 2nd Workshop on Flexible Resource and Application Management on the Edge, FRAME ’22,
p. 3–8, New York, NY, USA, 2022. Association for
Computing Machinery.
[12] 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.
[13] Dylibso, Inc. Observability in webassembly —dylibso developer resources. https://dev.dylibso.
com/docs/observe/overview, 2024. (Accessed on
08/14/2024).
[14] Bryan M. Cantrill, Michael W. Shapiro, andAdam H. Leventhal. Dynamic instrumentation of
production systems. In 2004 USENIX Annual Technical Conference (USENIX ATC 04), Boston, MA,
June 2004. USENIX Association.

[15] Isaac Gouy.
mandelbrot rust #4 program(benchmarks game). https://benchmarksgame-team.
pages.debian.net/benchmarksgame/program/mandelbrot-rust-4.
html. (Accessed on 08/15/2024).
[16] The Linux Kernel Organization. Perf wiki.
https://perf.wiki.kernel.org/index.php/Main_Page.
(Accessed on 08/16/2024).
[17] Matthew Kolosick, Shravan Narayan, Evan
Johnson, Conrad Watt, Michael LeMay, DeepakGarg, Ranjit Jhala, and Deian Stefan. Isolation
without taxation: near-zero-cost transitions for webassembly and sﬁ. Proc. ACM Program. Lang.,
Vol. 6, No. POPL, jan 2022.
[18] Raven Szewczyk, Kimberley Stonehouse, Antonio Barbalace, and Tom Spink. Leaps and bounds:
Analyzing webassembly s performance with a focus on bounds checking. In 2022 IEEE International Symposium on Workload Characterization(IISWC), pp. 256–268, 2022.
[19] Shravan Narayan, Tal Garﬁnkel, Mohammadkazem Taram, Joey Rudek, Daniel Moghimi, Evan
Johnson, Chris Fallin, Anjo Vahldiek-Oberwagner,
Michael LeMay, Ravi Sahita, Dean Tullsen, andDeian Stefan. Going beyond the limits of sﬁ: Flexible and secure hardware-assisted in-process isolation
with hﬁ. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, ASPLOS 2023, p. 266–281, New York, NY,
USA, 2023. Association for Computing Machinery.
[20] Abhinav Jangda, Bobby Powers, Emery D.
Berger, and Arjun Guha. Not so fast: Analyzing the performance of WebAssembly vs. nativecode. In 2019 USENIX Annual Technical Conference (USENIX ATC 19), pp. 107–120, Renton, WA,
July 2019. USENIX Association.