OSDI '22 - Debugging the OmniTable Way

USENIX
USENIXApr 7, 2026

Why It Matters

OmniTable could dramatically cut debugging time and overhead, enabling developers to diagnose production‑grade bugs with SQL‑style queries rather than fragile instrumentation, accelerating software reliability.

Key Takeaways

  • OmniTable treats program execution as a queryable database table
  • Reduces debugging code complexity significantly up to fifteenfold
  • Achieves 95× faster query resolution versus traditional tools
  • Lazy materialization and replay enable feasible storage and low overhead
  • Multi‑replay optimization parallels database join planning for speed

Summary

The talk introduced the OmniTable query model, a novel debugging approach that records a program’s execution as a massive relational table and lets developers interrogate it with SQL. By decoupling observation from runtime, the model promises to replace ad‑hoc instrumentation and print‑statement debugging with declarative queries.

Traditional debugging tools force developers to embed costly instrumentation or manage multiple data structures, inflating both code complexity and execution overhead. The speaker demonstrated that Diane’s cache‑leak investigation required dozens of lines of procedural code, whereas an equivalent OmniTable query can be expressed in a handful of SQL statements. Empirical evaluation across five open‑source bugs showed a geometric‑mean reduction of 15× in code size and a 95× speedup in query execution compared with GDB Python scripts.

A concrete example involved computing the working‑set size of a cache by sliding a 10,000‑call window over “get_item” invocations and counting distinct keys. The SQL query leveraged derived views such as “functions” and “stores,” producing a time‑series that could be plotted instantly. The presenter highlighted that the prototype, SteamDrill, uses lazy materialization and deterministic record‑and‑replay to avoid the prohibitive storage cost of capturing every instruction.

If the approach scales, developers could debug production systems with near‑zero overhead, iterating faster and reducing the risk of introducing new bugs during investigation. The combination of database‑style optimization and replay‑based execution positions OmniTable as a potential new standard for high‑performance, low‑complexity debugging in complex software stacks.

Original Description

OSDI '22 - Debugging the OmniTable Way
Andi Quinn, UC Santa Cruz; Jason Flinn, Meta; Michael Cafarella, MIT; Baris Kasikci, University of Michigan
Debugging is time-consuming, accounting for roughly 50% of a developer's time. To identify the cause of a failure, a developer usually tracks the state of their program as it executes on a failing input. Unfortunately, most debugging tools make it difficult for a developer to specify the program state that they wish to observe and computationally expensive to observe execution state. Moreover, existing work to improve our debugging tools often restrict the state that a developer can track by either exposing incomplete execution state or requiring manual instrumentation.
In this paper, we propose an OmniTable, an abstraction that captures all execution state as a large queryable data table. We build a query model around an OmniTable that supports SQL to simplify debugging without restricting the state that a developer can observe: we find that OmniTable debugging queries are more succinct than equivalent logic specified using existing tools. An OmniTable decouples debugging logic from the original execution, which SteamDrill, our prototype, uses to reduce the performance overhead of debugging. The system employs lazy materialization: it uses deterministic record/replay to store the execution associated with each OmniTable and resolves queries by inspecting replay executions. It employs a novel multi-replay strategy that partitions query resolution across multiple replays and a parallel resolution strategy that simultaneously observes state at multiple points-in-time. We find that SteamDrill queries are an order-of-magnitude faster than existing debugging tools.

Comments

Want to join the conversation?

Loading comments...