Reversible Execution

Reversible execution creates computers that seem to run backwards, applying time shifting techniques with simulation/virtualisation. They address the problems of software unreliability and complexity, and I believe my excited comments from 2005 still stand:

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

At the same time, the equally interesting topics of logical reversibility and thermodynamic reversibility have become very important. They are not really anything to do with reversible execution, they just sound similar. But if you’re interested in the problems AI datacentres present the world, this kind of reversibility looks highly relevant.

What is 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 is increasing, 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.

Greg Law has an excellent 2024 video presentation of the principles of time travel debugging.

Outlook for reversible execution

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

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:

• 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, 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.