VLDB 2026 Research / reviewers in the wild / expert
Zixi An
dblp:405/8685
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2025
—ORCID · unresolved
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Program analysis · 67% Runtime systems and virtual machines · 33% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Runtime systems and virtual machines › virtual machine implementation
bytecode rewriting |
0.9 | 1 | 2025 | Debugging WebAssembly? Put Some Whamm on It! · Proc. ACM Program. Lang. 2025 |
Program analysis
dynamic analysis |
0.9 | 1 | 2025 | Debugging WebAssembly? Put Some Whamm on It! · Proc. ACM Program. Lang. 2025 |
Program analysis › dynamic analysis
instrumentation |
0.9 | 1 | 2025 | Debugging WebAssembly? Put Some Whamm on It! · Proc. ACM Program. Lang. 2025 |
Methods — techniques the papers use, named apart from their topics
static and dynamic predication · 0.9intrinsification · 0.9declarative match rules · 0.9
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2025 | Debugging WebAssembly? Put Some Whamm on It!abstractDebugging and monitoring programs are integral to engineering and deploying software. Dynamic analyses monitor applications through source code or IR injection, machine code or bytecode rewriting, virtual machine APIs, or direct hardware support. While these techniques are viable within their respective domains, common tooling across techniques is rare, leading to fragmentation of skills, duplicated efforts, and inconsistent feature support. We address this problem in the WebAssembly ecosystem with Whamm, an instrumentation framework for Wasm that uses engine-level probing and has a bytecode rewriting fallback to promote portability. Whamm solves three problems: 1) tooling fragmentation, 2) prohibitive instrumentation overhead of general-purpose frameworks, and 3) tedium of tailoring low-level high-performance mechanisms. Whamm provides fully- programmable instrumentation with declarative match rules, static and dynamic predication, automatic state reporting, and user library support, achieving high performance through compiler and engine optimizations. The Whamm engine API allows instrumentation to be provided to a Wasm engine as Wasm code, reusing existing engine optimizations and unlocking new ones, most notably intrinsification, to minimize overhead. A key insight of our work is that explicitly requesting program state in match rules, rather than reflection, enables the engine to efficiently bundle arguments and even inline compiled probe logic. Whamm streamlines the tooling effort, as its bytecode-rewriting target can run instrumented programs everywhere, lowering fragmentation and advancing the state of the art for engine support. We evaluate Whamm with case studies of non-trivial monitors and show it is expressive, powerful, and efficient. Elizabeth Gilbert, Matthew Schneider, Zixi An, Suhas Thalanki, Wavid Bowman, Alexander Y. Bai, Ben L. Titzer, Heather Miller |
Proc. ACM Program. Lang. | 3 |