Re: [dev-servo] Omar Mozilla Intern Introduction
> 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 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
Re: [dev-servo] Omar Mozilla Intern Introduction
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 > 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
Re: [dev-servo] Omar Mozilla Intern Introduction
On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey wrote: > 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! > I think you'll easily beat rr overhead if your hypothesis is correct and recording channel nondeterminism suffices to make replay actually work --- even ignoring parallelism. It sounds like a great experiment and it'll be interesting to see how that works out! 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
Re: [dev-servo] Omar Mozilla Intern Introduction
The thing that has me slightly worried is that there may be a source of nondeterminism buried in a library where we can't get at it that ends up influencing Servo a lot. Gulp, not much we can do other than try it and see. Computing is n experimental science and all that. On Tue, Jun 4, 2019 at 7:15 PM Robert O'Callahan wrote: > On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey wrote: > >> 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! >> > > I think you'll easily beat rr overhead if your hypothesis is correct and > recording channel nondeterminism suffices to make replay actually work --- > even ignoring parallelism. > > It sounds like a great experiment and it'll be interesting to see how that > works out! > > 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
