Thanks for the emacs pointer. Interesting. It screams of continuations.
I know how to do snapshots of a process, what with criu. But if I just want a checkpoint to go back later, not a full serialization, and I don't want to save/restore a complete process, but take advantage of fork()'s CoW to save the least possible in a stopped process, then be able to come back. The rest of fork()' semantics are a problem, with threads, sockets, signals that are not passed down. An example of that approach is perf-fuzz where they add a new syscall to make fuzzing faster.
From memory rr has a substantive recording overhead, and is specially made for debugging, right? But yes it is very useful to analyse a past state and to understand a chain of events.
I should clarify my use case: I would use such a feature (go back to previous state) for a speculative execution tool. I'd execute the happy path all the time assuming no error occured, but if I found out later that something went wrong somewhere, I'd want to go back and start from there knowing what went wrong, and so on. With as little perf loss as possible. Not sure my explanation makes sense.
I know about dmtcp, criu, vm snapshots, but they all come with big overhead (I don't want to pay too much for the checkpoint).
The closest I found was @gamozolabs amazing work on snapshot fuzzing (pushing the limit of what's possible on x86_64 hardware, including using Intel PML - similar to userfaultfd but hw-accelerated...).
I know how to do snapshots of a process, what with criu. But if I just want a checkpoint to go back later, not a full serialization, and I don't want to save/restore a complete process, but take advantage of fork()'s CoW to save the least possible in a stopped process, then be able to come back. The rest of fork()' semantics are a problem, with threads, sockets, signals that are not passed down. An example of that approach is perf-fuzz where they add a new syscall to make fuzzing faster.
[0] https://github.com/sslab-gatech/perf-fuzz