3 ms·

Yes, this is true. Genuine parallelism will absolutely be a problem there - similarly to how it is for user-level record/replay tech. And serialising is going

Yes, this is true. Genuine parallelism will absolutely be a problem there - similarly to how it is for user-level record/replay tech. And serialising is going to have more impact when you're recording a whole OS vs just one application. Microsoft's TTD (a user-level tech) does allow genuine parallelism, I believe. But my understanding is that it has slower (though still very impressive) single-threaded performance as a result, so there's a tradeoff. But perhaps you could do something more like that. We believe it's possible to handle parallelism in record/replay tech while still having good single-threaded performance - but it implies a much more complex implementation to do so safely.

Veserv 2y ago
The literature on Microsoft TTD [1][2] indicates it is a instruction emulator full-trace approach. It is a little unclear if it is a basic emulator or a instrumented JIT approach, but the reported ~10x overhead is more consistent with a basic emulator. Though maybe their recording implementation is just inefficient causing such excess overhead. [1] https://msrc.microsoft.com/blog/2019/05/time-travel-debugging-its-a-blast-from-the-past/ https://msrc.microsoft.com/blog/2019/05/time-travel-debuggin... [2] https://www.usenix.org/legacy/events/vee06/full_papers/p154-bhansali.pdf https://www.usenix.org/legacy/events/vee06/full_papers/p154-...