Mutable Replay

Robert O'Callahan robert at
Mon Apr 22 19:27:46 PDT 2013

On Sun, Apr 21, 2013 at 7:37 PM, Nimrod Partush <nimrodpar at> wrote:

> I'd love to get your input on the paper and also on Scribe (as they claim
> it performs with very low overhead).

There are a few major differences between Scribe and rr:
-- Scribe doesn't serialize all threads. Instead they do a bunch of work to
make sure all threads can run simultaneously. This reduces overhead in some
places and adds overhead in others.
-- They say their approach doesn't require "changing, relinking or
recompiling the kernel" but their approach has to track internal kernel
state like inodes and VFS path traversal, and it's not really clear how
they do that. They also say "Scribe records by intercepting all
interactions of processes with their environment, capturing all
nondeterminism in events that are stored in log queues inside the kernel"
so my guess is they're using a kernel module. That's a pretty big negative
in my view.
-- Scribe doesn't use performance counters to record asynchronous events.
Instead they defer signal delivery until the next time the process enters
the kernel. If the process doesn't enter the kernel for a long time, they
basically take a snapshot of the entire state, force the process into the
kernel and restart recording --- extremely heavyweight. For some bugs, it's
essential to allow async signal delivery at any program point, so I don't
like Scribe's approach there.

q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rr-dev mailing list