improving replay performance

Robert O'Callahan robert at
Sat Nov 21 00:02:34 UTC 2015

On Sat, Nov 21, 2015 at 12:22 PM, Chris Jones <jones.chris.g at>

> On Fri, Nov 20, 2015 at 3:06 PM, Robert O'Callahan <robert at>
> wrote:
>> On Sat, Nov 21, 2015 at 12:00 PM, Chris Jones <jones.chris.g at>
>> wrote:
>>> On Thu, Nov 19, 2015 at 6:32 PM, Robert O'Callahan <robert at
>>> > wrote:
>>>> * After we've replayed a set of buffered syscalls, we need to induce a
>>>> ptrace stop so that rr can regain control and begin replaying the following
>>>> event. I've thought of many ways to do this, none of which are wholly
>>>> satisfying.
>>> ​I don't quite understand the problem here ... since the buffer flush
>>> (virtual event) was triggered by the next (real) event, can't we just
>>> discard the buffer flush event after restoring the saved data and start
>>> replaying the next one?​
>> In most cases, yes, but sometimes after flushing the last event we need
>> to set the notify_on_syscall_hook_exit flag.
> ​Ah, that's a new one for me :).  How about recording an event when you
> set the flag during recording?

That's how we handle signals during syscall buffering now, by setting that
flag. We don't want to record an event for setting that flag because we
can't safely replay to it. You have given me an idea though: replace the
boolean flag with a num_rec_bytes to stop at. Then during replay we can set
the flag early and we'll stop after the correct event, and the control flow
will be the same as during recording.

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the rr-dev mailing list