4 ms·

I believe all of those projects are based on single-core debugging. Restricting the trace to a single core is one way of introducing determinism in the process

I believe all of those projects are based on single-core debugging. Restricting the trace to a single core is one way of introducing determinism in the process as a way of allowing replay later. Microsoft time travel debugging is a multi-core technology, which allows you to capture interactions between threads in multi-threaded processes. Edit: Since I'm still "posting too fast", let me respond here to clarify. Both rr and undodbg support multiple threads, but do not record them simultaneously. They restrict execution to a single core. That's what I mean by recording interactions between threads. For instance, if you have shared memory between processes, that won't work with rr/undodb generally (although I know at least rr can work around this by recording both processes). I'm not saying one is intrinsically better than the other since there are tradeoffs with both approaches. There is a high constant overhead for recording all cores, but it does have the advantage of scaling well to large numbers of cores.

kuwze 9y ago
rr does support multithreading[0]. "rr doesn't record shared-memory multithreading, so it forces your application's threads to execute serially. Your application can see an additional slowdown if it takes advantage of multicore parallelism." [0]: https://github.com/mozilla/rr/wiki/Usage#recording-an-execution https://github.com/mozilla/rr/wiki/Usage#recording-an-execut...
Game_Ender 9y ago
UndoDB supports threading [0]: "Handles concurrency Record and replay multi-threaded programs, and those that use shared memory and asynchronous I/O." [0] - https://undo.io/technology/features/ https://undo.io/technology/features/
khuey 9y ago
Yes, there is definitely a significant tradeoff here. If you're recording something like Exchange Server having true multi-core execution is a big deal. If you're recording a web browser it's not as important, because most things are still gated on the UI thread. Hopefully y'all can get the constant factor overhead for recording down further over time. With rr and Firefox we found that with sufficiently pathological scheduling we can eventually tease out many races and other bad thread interactions. This became rr's "chaos mode". I think the biggest drawback of not having true multi-core support in rr today is simply the performance hit that a parallel program will take during recording.

kuwze 9y ago

rr does support multithreading[0]. "rr doesn't record shared-memory multithreading, so it forces your application's threads to execute serially. Your application can see an additional slowdown if it takes advantage of multicore parallelism." [0]: https://github.com/mozilla/rr/wiki/Usage#recording-an-execution https://github.com/mozilla/rr/wiki/Usage#recording-an-execut...

Game_Ender 9y ago

UndoDB supports threading [0]: "Handles concurrency Record and replay multi-threaded programs, and those that use shared memory and asynchronous I/O." [0] - https://undo.io/technology/features/ https://undo.io/technology/features/

khuey 9y ago

Yes, there is definitely a significant tradeoff here. If you're recording something like Exchange Server having true multi-core execution is a big deal. If you're recording a web browser it's not as important, because most things are still gated on the UI thread. Hopefully y'all can get the constant factor overhead for recording down further over time. With rr and Firefox we found that with sufficiently pathological scheduling we can eventually tease out many races and other bad thread interactions. This became rr's "chaos mode". I think the biggest drawback of not having true multi-core support in rr today is simply the performance hit that a parallel program will take during recording.