Skip to main content
← Back

whamm: Wasm Instrumentation and the Component Model

The June 25, 2025 wasmCloud community call welcomes Elizabeth Gilbert, a Carnegie Mellon PhD student researching WebAssembly instrumentation, who demos whamm — a DTrace-inspired DSL for dynamic analysis that rewrites Wasm bytecode (or hooks an engine at runtime) to count calls, profile branches, and build flame graphs. The conversation turns to bringing whamm to the Wasm component model, then the maintainers declare "pull request bankruptcy" — a plan to unblock a backlog of high-quality PRs stuck behind flaky tests — and congratulate two new maintainers.

Key Takeaways​

  • whamm ("Wasm Application Monitoring and Manipulation") is a framework from Elizabeth Gilbert's CMU research that lets you instrument WebAssembly using a high-level DSL inspired by DTrace, choosing either static bytecode rewriting or dynamic instrumentation through the Wizard research engine
  • Two instrumentation strategies ship today: static rewriting injects logic directly into the Wasm bytecode at matched event locations, while dynamic instrumentation runs a standalone instrumentation module whose callbacks fire as events occur in the host engine
  • A live calls-monitor demo showed whamm matching call opcodes by predicate, binding scope variables like function ID and PC offset, and injecting a counter before each matched call — all driven by the whamm CLI's instrument and info commands
  • Observability is a headline use case: Bailey Hayes highlighted adding logging and tracing to a component after the fact — instrumenting a third party's code to see how it uses sockets or other capabilities without editing the source
  • A cache-simulator feature lets whamm scripts call into a user-supplied Wasm library, keeping the DSL focused on stitching program state to logic while libraries do the heavy lifting — a pattern that also curbs DSL scope creep
  • Component model support is next: whamm builds on the Orca Rust library, which can already instrument components, so Elizabeth plans to expose component instrumentation in the DSL over the following weeks
  • The maintainers declared "pull request bankruptcy," agreeing to disable flaky tests (with bug reports filed) via a single tracked PR so a backlog of complete, approved contributions can finally merge
  • Lachlan (TypeScript maintainer, now also reviewing CI) and Massoud (capability providers) were welcomed as new wasmCloud maintainers

Chapters​

Meeting Notes​

Demo and Discussion: Wasm Instrumentation with whamm​

Elizabeth Gilbert, a third-year doctoral student at Carnegie Mellon researching WebAssembly instrumentation, joined the call to share whamm — "Wasm Application Monitoring and Manipulation." Instrumentation, she explained, is the ability to inject logic into a program so you can do dynamic analysis while it runs: branch profiling, call graphs, flame graphs, and the like. whamm expresses that instrumentation in a DSL inspired by DTrace, where you declare the high-level events you want to hook and the logic to run when they fire.

whamm supports two strategies. Static bytecode rewriting scans your Wasm bytecode, injects logic at matched event locations, and emits a new instrumented module. Dynamic instrumentation keeps a standalone instrumentation module that the engine loads as a side artifact — built on the Wizard research engine — firing callbacks as events occur in the running program.

Demo: A Calls Monitor in whamm​

Elizabeth walked through a demo from the whamm repository that counts function calls. A match rule targets the call opcode, with predicates narrowing it down (for example, only calls to function ID two, or only calls inside a given function). She showed how parts of the match rule bind variables into scope — the Wasm provider exposes things like function ID, PC offset, and the function name — and used the CLI's info command to discover those bound variables, then instrument to rewrite the module. Printing the instrumented module to WAT revealed the injected counter logic running before each matched call; executing it on Wizard reported how many times each probe's count was incremented. She noted the DSL also supports globbing to match patterns of opcodes and a report keyword that flushes results at end of execution.

From Observability to the Component Model​

Bailey Hayes zeroed in on the observability angle: with whamm you could add logging and tracing to a Wasm component after the fact — instrumenting someone else's code to see, say, how it uses a socket — without editing the source. Elizabeth described a recently built cache simulator that lets a whamm script call into a user-supplied Wasm library, keeping the DSL lean while libraries handle sophisticated logic. Bailey framed whamm as a future staple of the platform engineer's toolbox, usable in CI/CD or at runtime via Wizard. Elizabeth said she is working toward higher-level, source-mapped (DWARF) events for non-low-level users, and — answering Brooks — confirmed component model support is on the near-term roadmap: whamm's backend, the Orca Rust library, can already instrument components (work Victor Adossi had also explored), so it is mostly a matter of exposing it ergonomically in the DSL.

Discussion: Pull Request Bankruptcy​

Brooks Townsend introduced "pull request bankruptcy": a backlog of complete, approved, or roadmap-driven PRs in the main wasmCloud repo has been stuck behind a recurring set of flaky tests — notably a built-in HTTP server path-routing test Brooks added that fails for unrelated changes. The proposal: rather than force-merging or disabling all merge protections, disable the offending tests in a single PR, file bug reports for each, and link them in a meta tracking issue so the backlog (Aditya's cron-job provider and memory-limit work, Massoud's NATS Blobstore and built-in HTTP client providers, and others) can land. Liam Randall ("I've wanted to eat that thing into the sun for a long time") agreed, and Massoud (ossfellow) suggested shifting validation onto PR owners — asking each author to confirm whether their failing tests are actually related. The group agreed to open a meta issue, give it a week of comments, then merge one consolidating PR that everyone can rebase onto.

Congratulations to New Maintainers​

Brooks closed by congratulating two new maintainers: Lachlan, a longtime TypeScript maintainer who has contributed extensively to wasmCloud's CI pipelines and now helps review CI, and Massoud, now a maintainer for capability providers after contributing the NATS Blobstore provider, the built-in HTTP client provider, and broad feedback across the ecosystem.

WebAssembly News and Updates​

This call is a window into where WebAssembly tooling is heading: dynamic analysis and observability built directly on the Wasm execution model. whamm carries the ideas of DTrace into WebAssembly via a purpose-built DSL, riding on the Wizard research engine for runtime instrumentation and the Orca library for component-aware bytecode manipulation. The recurring theme — making instrumentation work for the Wasm component model — mirrors the broader ecosystem's push to move every tool from raw modules up to typed components. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, distributes workloads as OCI artifacts, and connects everything over NATS. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure — and tools like whamm point toward even richer introspection of the components running on it.

Topic Deep Dive: The Wasm Component Model​

Even a call centered on instrumentation kept circling back to the Wasm component model. whamm's demo ran against raw Wasm modules, but its most-requested next step is component support — because most of the wasmCloud ecosystem builds with components, not bare modules. Components carry higher-level metadata and typed interfaces that a tool like whamm can key off, making instrumentation both more powerful and more user-friendly: instead of matching low-level call opcodes, you could hook semantically meaningful boundaries. That metadata is exactly what makes the component model the universal contract across languages and hosts — and it is why whamm's backend (Orca) already invests in component-aware manipulation. As more tooling crosses from modules to the component model, the promise of observability, profiling, and analysis that "just works" on any Wasm component — regardless of source language — gets meaningfully closer.

Who Should Watch This​

This call is especially valuable for platform engineers and SREs evaluating how to add observability and profiling to WebAssembly workloads after deployment (start with Bailey's use-case discussion at 16:59), WebAssembly tooling and language-runtime developers curious about DTrace-style dynamic analysis and the path to component-level instrumentation (Elizabeth's whamm demo from 4:50), and open-source maintainers wrestling with flaky tests and PR backlogs who want a pragmatic playbook for declaring "pull request bankruptcy" (the maintainer discussion at 26:43).

Up Next​

Watch for whamm gaining Wasm component model support in the weeks following this call — Elizabeth invited the community to try it out (and report bugs) once components land, ideally via the wasmCloud Slack. On the project side, expect the meta tracking issue for flaky tests to fill up, followed by a single consolidating PR that disables the offending tests and unblocks the merge backlog.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →