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:

Reversibility is the biggest advance in debugging since source code debugging

— Me, on the GDB developers list ↗

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

đź’ˇ
Confusingly similar names I also have an article on the totally different but similar-sounding topics of logical reversibility and thermodynamic reversibility . If you’re interested in the problems power-hungry AI datacentres present the world you might find it interesting.

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 precisely 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 ↗ is in its early stages and cannot yet do reverse execution, but I mention it because reversible targets are still rare.

Illustration of program flow in Renode reversible debugging
Illustration of program flow in Renode reversible debugging

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. Until recently, relatively few developers seem interested in these features, despite offering visibility into very complicated problems.

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. By using a simulation approach instead, Wind River’s Simics ↗ ’ reverse execution feature still exists, although only mentioned in passing in training material ↗ . Jakob Engblom’s Comprehensive Reversibility List ↗ is maintained by my former Simics colleague, and it has very few entries since the dawn of commercial source code debugging.

But why? The wealthy toolmaking companies of the world know reversibility of arbitrary electronics devices can be done at speed and scale, down to microcode resolution where necessary.

Some open source solutions exist:

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, closed-source WinDbg Preview (available through Visual Studio) supports Time Travel Debugging (TTD) ↗ , and LiveRecorder ↗ is a 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 .