- https://undo.io/ (It can also support Golang https://docs.undo.io/GoDelve.html)
- Mozilla RR https://rr-project.org/
- GDB https://www.gnu.org/software/gdb/news/reversible.html
Unfortunately, works only in Linux.
Of course, it doesn't rollback the heap or any shared state. And playing forward again it will redo things again. So beware of side effects. But in codebases with lots of immutable data structures (Kotlin ftw) it works great.
Combined with hot swapping, one can even drop the frame, change the implementation of the function and then reenter, making it possible to test code changes without spending long time getting back into the same state/context.
One thing I wish Java debuggers supported was the ability to move the instruction pointer to a different line, as has been possible in other debuggers for ages. Is it a JVM limitation maybe? I remember being able to drag the "current line" pointer forwards or backwards in languages like C, C++, and C# in maybe 2003. I wish I could do this with Java; dropping the whole frame is useful but this feature lets you do a lot more, like break out of a loop or skip a block of code you _just_ realized shouldn't execute.
> if you want to jump to a particular line and set an execution point there, without executing the preceding code
This is because Visual Studio debugger was always state of the art.
AFAICR Borland's IDEs had that before the turn of the century.
All the debuggers mentioned above for the backend work only under Linux, because from what I understand, they use `ptrace` syscall, and on Mac have completely different format, and different capabilities.
Do you plan support Golang, especially on Mac, maybe with custom fork, or similar?
Thank you!
The runtime infrastructure can support all of those. The current recorded browser runs on mac, and the mac image is replayed in a linux backend (with the system calls being handled by the replay engine).
Our initial launch is with a modified Firefox browser on Mac, but the infrastructure itself is generalizable to other runtimes and other operating systems.
However, we do need to "paravirtualize" the runtimes that are recorded on our system (modify the underlying runtime to make it aware that it's being recorded, and do some integration work for each runtime). The design of our system allows for new runtimes to plug in and use all the same infrastructure for replaying.
So the long answer is that we can support them, but support for each runtime will arrive as we prioritize and complete the implementation for them.
Currently we have the mac Firefox-forked browser. In the works we have a chrome browser, nodejs backend, and a firefox fork for windows. But realistically we should be able to support `(any runtime x any os)` within reasonable bounds. Record and replay all the things :)