WebAssembly VM in Nock
summary
Runs a WebAssembly interpreter compiled into Nock using a Wasm3 fork hardened for determinism, proving jets can execute complex non‑Nock code with minimal marshalling. State is represented as an event log and accelerated with persistent partial memoization so replaying external calls caches intermediate VM snapshots. Measured overhead is concrete: 400ms stateless vs 500ms stateful with state-serialization taking milliseconds and ~20% slowdowns on some control‑heavy workloads. Worked well for JavaScript integration in Urbit messenger, WAT via a Rust wat2wasm, and an SDK for user scripts.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:47Conventional software in Nock
- 3:56Optimizing Nock with jets
- 8:50WebAssembly interpreter design
- 11:19Script representation challenges
- 15:57WebAssembly text format
- 17:25IO in WebAssembly jets
- 18:29Memoization in Nock
- 22:12Performance of stateful WebAssembly
- 23:59Future directions
- 24:21Q&A
related talks
46mA State Of WebAssembly - The Browser is now a real VM
22mThe state of WebAssembly
50mWeb Assembly
45mWebAssembly: Browser is now a real virtual machine
01h 42mWebAssembly: Writing Once and Running Everywhere NG
42mWebAssembly? Web and Assembler? WTF!
44mWebAssembly
44mWebAssembly and the Future of the JVM Ecosystem