Omar Mozilla Intern Introduction

[Omar Salvador Navarro Leija]

Hello everyone!

My name is Omar Navarro Leija. I am interning for the summer at Mozilla SF
as part of the Servo group.

I am a 4th year PhD student at the University of Pennsylvania. I am
interested in systems programming, operating systems, and concurrency. My
current research focuses on deterministic parallelism and dynamic
determinism enforcement.

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 :)

I look forward to contributing to Servo and learning a lot!

Omar

[Robert O'Callahan]

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.

[Omar Salvador Navarro Leija]

> 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:

> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>

[Alan Jeffrey]

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 <

[Robert O'Callahan]

On Wed, Jun 5, 2019 at 4:16 AM Alan Jeffrey <ajef...@mozilla.com> 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!

[Alan Jeffrey]

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 <rob...@ocallahan.org>
wrote: