Reversible Execution

Reversible execution creates computers that seem to run backwards, applying time shifting techniques with simulation/virtualisation to address software unreliability and complexity. I stand by my excited comments from way back in 2005:

In 2026, reversibility still isn’t seen as an ubiquitous must-have for software development, but awareness is increasing.

What is checkpoint-based reversible execution?

Reversible execution is about giving the appearance of a program executing backwards in time. If you’ve not seen it before, it is just as strange and impressive as it sounds.

It is possible to have a whole network of running computers - say, Android, Windows, Linux running on miscellaneous hardware - and then to stop them all and reverse back to any point in time. For example, reversing to a point just before a catastrophic error occurred, so we can watch carefully as it runs forward from that point. And repeat it if we want to, again and again, any number of times. Imagine installing an operating system you know nothing about, starting an application… and then running the process in reverse as it unboots, scrolling up the screen until it switches off. This is true reversibility from the point of view of a systems or application developer: you have a slider bar for time. The underlying mechanism is a record-replay trick. On the first pass, all non-deterministic inputs to the system (keyboard events, network packets, hardware interrupts, clock values) are logged to disk. On replay, those same inputs are fed back at the right moments, making execution deterministic and therefore repeatable from any captured point.

Unreliable software stacks are common, and it affects whole societies. A large part of the problem is due to complexity in software, and I have seen reversibility reduce this by making debugging much easier to do.

There is an excellent 2024 video presentation ↗ by Greg Law on the principles of time travel debugging.

Checkpointing first, then reverse execution

Renode ↗ is an open-source development simulator for embedded hardware architectures such as RISC-V, ARM Cortex M etc with multiple CPUs each. Renode’s reversible debugging ↗ does reverse execution on single cores and improvements are expected.

By periodically saving the system’s state (memory, registers, and peripheral configurations) during emulation, Renode creates a series of checkpoints. When a developer issues a gdb reversible command such as reverse-continue, Renode resets the simulation state from the checkpoint at the breakpoint. Renode uses these snapshots to reconstruct the state and re-execute the software up to the desired instruction.

For the more complex systems described in the previous section, the process is exactly the same but the implementation needs to save state extremely fast with storage efficiency across multiple simulated CPUs and sets of peripherals. The full reversible execution effect is achieved by replaying snapshots as fast as possible in reverse order, that is:

• checkpoint t-1 is restored, and then executed forwards until time t
• checkpoint t-2 is restored, and executed forwards until time t-1
• checkpoint t-3 is restored, and executed until time t-2, etc.

If checkpoints are sufficiently fine-grained, the system gives the appearance of running backwards, to the point that a party trick is to run a graphical operating system’s analogue desktop clock app to watch it whizzing around in reverse as it rapidly restores snapshots, right back to the operating sytem starting and then the bios initialising, and then power on, and then it is finished.

Outlook for reversible execution

In 2026 the world has not yet agreed with my enthusiasm for reversibility, but even so:

1. Full execution reversibility of simulated systems at high speed is possible - including even running and operating system backwards, even unbooting. This is well-understood computer science.
2. The ability to rewind and replay at an application level is powerful for debugging, especially for complex stacks, and rare or non-deterministic bugs.
3. Full-system reversibility has a severe maintenance cost: every processor and peripheral model must support checkpointing, restoration and deterministic replay. One defective model can break reversibility for the whole simulated system.

VMware Player dropped reversibility in 2011 ↗, citing not enough people demonstrated the need or invested the time necessary to configure and use the feature. And to be fair, VMware is a hypervisor technology where virtual machines have access to the underlying CPU, and modern CPUs are significantly ↗ non-deterministic ↗, so this is very hard to implement.

Simics failed for a different reason ↗. Intel removed reverse execution from Simics 7 and replaced it with in-memory snapshots. Jakob Engblom explains that the simulator framework worked, but most models of real hardware did not. Every model had to save and restore its complete state and execute deterministically. After Intel expanded pre-silicon model development, delivery deadlines mattered more than maintaining models after the corresponding hardware shipped. Reverse execution worked on polished demonstration systems such as the generic PC model, but not on most systems customers actually used.

Wind River now supplies and supports Intel Simics ↗ rather than a separate Simics product, and its current releases use Simics 7. The snapshots retained enough machinery for Mike Thompson of RESim ↗ to rebuild the reverse-to-breakpoint and skip-to operations in Python, with performance close to native reversing in his tests. The vendor removed reverse execution from the framework, and a user reconstructed the parts he needed above it.

Jakob Engblom’s Comprehensive Reversibility List ↗, written by my former Simics colleague and last updated in 2018, is a useful historical survey of roughly fifteen implementations.

Some open source solutions exist:

• Eclipse CDT ↗ has support for driving reversible targets, including full-system targets via the GDB MI ↗ interface
• There are several reversible user mode targets, notably rr ↗ originally from Mozilla, capable of rewind/replay of applications including QEMU, which itself can run systems within it
• CRIU ↗ and DMTCP ↗ are checkpointing primitives usable by a reverse debugger for distributed applications ↗ (2026)
• GDB does not need to be driven: it has a well-tested implementation of Record/Replay and Reversible Debugging. GDB can itself drive a reversible target, especially embedded targets

Robert O’Callahan is an eloquent campaigner ↗ for better debugging, one of the authors of Pernosco ↗, a commercial tool that uses rr traces. Robert says:

In the past, a lot of people simply did not believe that these tools could possibly do what we say they do. That is becoming less of a problem.

and I really hope that’s true.

Besides these, Microsoft’s closed-source WinDbg includes Time Travel Debugging ↗. It records user-mode processes for read-only playback, typically imposing a 10x to 20x recording overhead. The separate TTD.exe recorder can be installed on systems that do not need the debugger. LiveRecorder ↗ is another user-space record/replay solution. Perhaps one of these will spark a revolution. If you’re a student, try them out!

If I was starting to build reversibility for production use today, I would probably start prototyping with the QEMU Replay System ↗. This is accurate but a bit clunky and slow, but rapidly allows different techniques to be tried. I would also be looking at using AI to drive reversible simulation to find problems, rather than the old-fashioned manual method.

The annual Conference on Reversible Computation ↗ showcases a much more general view. This conference does include practical reversible computing as I describe above, but also explores the mathematics of reversibility including in the context of quantum computing. I can’t even begin to guess how quantum reversibility works at high resolution but seemingly it is regarded as feasible.

For more on what reversibility has to do with thermodynamics and AI datacentres, see my article on the topic.