I just saw a presentation that describes the rr vm/recorder in more detail. I am very impressed (though i haven't got the chance to use/test it). https://youtu

I just saw a presentation that describes the rr vm/recorder in more detail. I am very impressed (though i haven't got the chance to use/test it). https://youtu.be/H4iNuufAe_8 https://youtu.be/H4iNuufAe_8 pure science fiction - instead of recording the change produced by each instruction they are recording what changed between system calls (result of system call is recorded) and scheduling points. They do record the result of each system call and somehow manage to count the number of instructions per scheduled thread (they can only do that on new intel processors - counting the number of branches not instructions as instruction counter is not reliable. They are doing their own scheduling since the VM is all running in a single thread. It is also very Linux specific - for general case they use ptrace to record the system calls and their result, but tracing of some operating system calls is optimized by injecting stuff into the kernel (!)) - that's the reason why the recorded data is of minimal size. I wonder how they are dealing with epoll - here the result is passed via shared memory and not via the system call interface. Still i guess they are lucky that there is no kqueue like interface on Linux - with kqueue it would have been even harder to track when the event result comes in.