Flash Burst Computing

Flash burst computing is motivated by two growing trends: big data and cloud computing. Today, many businesses and web services store staggering quantities of data in the cloud and lease relatively small clusters of instances to run analytics queries, train machine learning models, and more. However, the exponential data growth, combined with the slowdown of Moore’s law, makes it challenging (if not impossible) to run such big data processing tasks in real-time. Most applications run big data workloads on timescales of several minutes or hours, and resort to complex, application-specific optimizations to reduce the amount of data processing required for interactive queries. This design pattern hinders developer productivity and restricts the scope of applications that can use big data.

My research aims to enable interactive, cost-effective big data processing through “flash bursts”. Flash bursts enable an application to use a large portion of a shared cluster for short periods of time. This could allow big data applications to complete significantly faster, with cost comparable to leasing a few instances for a longer period of time. A flash-burst-capable cloud could enable new real-time applications that use big data in ad hoc ways, without relying on query prediction and precomputation; e.g., a security intrusion detection system could analyze large-scale logs from many machines in real-time as threats emerge. It could also improve developer productivity (e.g., a machine learning researcher could train models and iterate on new ideas quickly). Finally, flash bursts could reduce costs, since applications would no longer need to precompute results for all potential queries.

5-minute introduction video:

Making flash bursts practical requires two capabilities that are missing today: the cloud must hand cores to an application within microseconds, and developers must be able to debug applications that run across many machines.

HyperFlux: microsecond-scale core provisioning

A shared cloud cannot keep hundreds of idle cores in reserve for every tenant that might burst. Bursty, data-intensive serverless workloads such as big-data analytics and DNN inference make this tension acute: their arrival rate can surge by orders of magnitude within a few milliseconds, and the right degree of parallelism is unknown until a query arrives. Today’s multi-tenant platforms cannot move physical cores between hardware-isolated virtual machines (VMs) at the speed these applications need.

HyperFlux (APSys ’25) is a hyperreactive virtualization stack that co-designs a virtual machine monitor, a lightweight guest OS, and a Linux kernel module that arbitrates cores among VMs. It reallocates cores between hardware-isolated VMs, and scales a VM’s cores up or down, within tens of microseconds. This brings the provisioning agility of KVM-isolated serverless platforms to the microsecond scale.

The full version of HyperFlux (preprint) is an ultralight VM substrate on commodity KVM that makes the number of physical cores backing a VM elastic at runtime. It moves a core across VMs in 13 µs, even when forcibly reclaiming the core from a busy VM, orders of magnitude faster than conventional vCPU hot-plug. A HyperFlux VM uses only 3.2 MB of memory and cold-boots in 1.37 ms, on par with the fastest-booting ultralight VMs, while still supporting multicore parallelism. Under colocation, HyperFlux reduces the tail latency of high-priority VMs by up to 10× under high load compared with static core sharing on Firecracker and Cloud Hypervisor.

DDB: interactive debugging for distributed applications

Spreading an application across many machines also makes it hard to debug. Interactive debuggers such as GDB let developers pause a program, walk the call stack, and inspect state, but only within a single process. In a distributed application, call stacks stop at process boundaries, debugging state is lost as processes come and go, and pausing one process triggers timeouts that cascade through the system. Developers fall back on slow cycles of adding logs and redeploying.

DDB (SOSP ’26) brings source-level interactive debugging to distributed applications. Distributed Backtrace embeds compact causality metadata in every RPC and reconstructs a single call stack across RPC boundaries. An intent-preserving control plane propagates breakpoints across a changing set of processes. Pause-Erased Time virtualizes each process’s clock, so a paused process no longer sets off timeouts elsewhere. DDB integrates with an RPC framework in 10–60 lines of code. On gRPC, ServiceWeaver, Nu, and Quicksand applications with up to 122 processes, DDB reconstructs a cross-RPC backtrace in 30 ms (median) and adds 1–5% throughput overhead. In a controlled user study, DDB achieved a 100% fault localization success rate, compared with 38.5% for baseline tools, with a median localization time of about 8 minutes.

See also the MilliSort project, which demonstrated large-scale data-intensive computing at millisecond timescales.