Poster: Feasibility of Runtime-Neutral Wasm Instrumentation for Edge-Cloud Workload Handover

Yuki Nakata (SAKURA internet Inc. / Future University Hakodate); Katsuya Matsubara (Future University Hakodate)

The Ninth ACM/IEEE Symposium on Edge Computing (SEC)
https://acm-ieee-sec.org/2024/index.php

Transcript

1. Feasibility of Runtime-Neutral Wasm Instrumentation for Edge-Cloud Workload Handover Yuki Nakata1,2, Katsuya Matsubara2 1 SAKURA internet Inc., Japan 2 Future University Hakodate, Japan Goal: Platform-neutral workload handover Towards implementation of a Wasm runtime optimized for self-hosting Which Wasm instrumentation is the most efficient and runtime-neutral? Suitable Wasm runtime depends on each platform • Different implementation and execution strategy (JIT, AOT and interpreter) … Rust C/C++ Bytecode WebAssembly (Wasm): Architecture independent VM Wasm Runtime A for Cloud VM Instrument Code Source Destination Dumping state Restoring state get_mem() Resume App Suspend App Live-migration with bytecode instrumentation: Empower moving application Insert programs into apps to obtain states • Dumping and restoring application states (e.g. stack, memory and pointer) Use powerful servers Follow the user's location • Use powerful servers • Follow the user’s location Any Wasm Runtimes and Strategies Self-hosted Wasm Runtime Instrumentation Mechanism Wasm Bytecode Memory Stack Program Counter • Compile it runtime to bytecode and run it on any runtimes • Implement instrumentation mechanism only in it • Eliminate effort to tailor for each runtime and execution strategy > Self-hosted runtime for instrumentation Faster than Wasabi Mandelbrot Set Computation Execution Time(sec) Wasm3 83.53 Self-hosted Wasm3 on Wasm3 3125.61 Wasmtime 14.02 Self-hosted Wasm3 on Wasmtime 1579.32 37x Slower 112x Slower > Feasibility evaluation Implemented instrumentation mechanism in Wasm3 (Existing self-host compilable runtime with interpreter) Instrumentation overhead Impact of performance by self-hosting runtime • Compared with cases without self-hosted instrumentation • Tracing memory usage • Compared with AOT instrument code inserting (Wasabi) • Remove duplication of memory boundary checks • known performance overhead factors of Wasm sandboxing • Offload atomic parts of instruction processing to native Wasm runtime 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%) Top 3 Instructions in Pi Calculation Increased memory instructions AOT instrument code inserting [1] ✓: Neutral to runtime and execution strategies ✘: Poor performance Dynamic instrumentation in runtime [2] ✓: High performance ✘: Depends on runtime and execution strategies > Existing methods [2] B. L. Titzer, E. Gilbert, B. W. J. Teo, Y. Anand, K. Takayama, and H. Miller, “Flexible Non-intrusive Dynamic Instrumentation for WebAssembly,” Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3, Apr. 2024. Runtime … local.get $p1 call $hoge … Instrumentation Mechanism For Interpreter For JIT … local.get $p1 probe … … local.get $p1 call $hoge … Wasm Bytecode … call $analysis local.get $p1 call $analysis call $hoge call $analysis … Instrumented Wasm Bytecode [1] D. Lehmann and M. Pradel, “Wasabi,” Architectural Support for Programming Languages and Operating Systems, Apr. 2019. Wasm Runtime B for Edge VM Wasm Runtime C for Device VM