We're interested in doing the experiment of how to increase the amount of determinism in a program like Servo where almost all the nondeterminism that's observable by Servo has a single cause (in Servo's case selecting on channels). There'll still be a lot of nondeterminism in the system (e.g. dependencies like rayon that do their own thread management) but hopefully not much that's observable within Servo, and in particular not much that causes intermittent WPT test failure. If this experiment works, there's then the question of what the overhead is compared to something like rr, my guess is that it'll be lower, but rr is very very good at its job, so it may be a hard target to beat!
Alan. On Tue, Jun 4, 2019 at 11:02 AM Omar Salvador Navarro Leija < ole...@mozilla.com> wrote: > > What's the motivation for doing this vs using an off-the-shelf record and > replay tool like rr? > Yeah, that's a really good question. This is just the rough idea for my > project and we're still shaping out the details. > > Some high level points: > - As you already mentioned, RR sequentializes execution of threads and > processes, the more parallel we are, the more costly RR is. We hope to > maintain parallel execution. > - RR is a complete solution, it catches all sources of nondeterminism. If > we think of testing, we believe for a given test, the main sources of > nondeterminism should be non-det thread scheduling, which we hope to > determinize via record-and-replay channels. Any remaining nondeterminism > will be from other sources which we probably want to track down, and ask if > this source should really be nondeterministic? RR is a little too good at > hiding these miscellaous sources from us. > - I hadn't thought about the non-Linux portability, but this could > certainly be an advantage! > - We hope to make our record-and-replay channels general, so they may be > useful to the wider Rust ecosystem. > > Omar. > > On Mon, Jun 3, 2019 at 5:58 PM Robert O'Callahan <rob...@ocallahan.org> > wrote: > > > On Tue, Jun 4, 2019 at 11:49 AM Omar Salvador Navarro Leija < > > ole...@mozilla.com> wrote: > > > > > This summer, I will be looking at taming a small piece of the > difficulty > > > with debugging parallel systems. Specifically, implementing > > > record-and-replay for Rust channels. This will hopefully make servo a > > > little easier to debug and a little more deterministic :) > > > > > > > What's the motivation for doing this vs using an off-the-shelf record and > > replay tool like rr? Ability to handle multicore parallelism? Ability to > > work on non-Linux? > > > > Rob > > -- > > Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot > > mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. > Efil > > fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta > > dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew > > hcihw, gninnigeb eht morf saw hcihw taht. > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
