1

Meeting 2013 11 04

Lars Bergstrom edited this page 2013-11-04 11:36:36 -08:00

Table of Contents

• Servo Meeting 2013-11-04
• Agenda
• Attending
• Samsung trip
• Mac builder failures
• Priorities

Servo Meeting 2013-11-04

Agenda

• Mac builder failures ( example: http://servo-buildbot.pub.build.mozilla.org/builders/mac/builds/510/steps/shell/logs/stdio )
• next year's priorities
  • layout
  • content
  • graphics
  • shell/embedding/arch

Attending

azita, brson, dherman, simonsapin, pcwalton, jdm, lbergstrom, jack, kmc

Samsung trip

• azita: bring a warm jacket! slacks or jeans + button-down / polo.
• azita: just bring laptop+power cord. No security sticks / writeable media. Phones should be fine. We have to go through a security check.
• simonsapin: can't join because I will be in Shenzhen. I can probably call in about CSS one day other than Monday or Tuesday.
• jack: what time works for you?
• simonsapin: just one hour time zone behind
• jack: we'll try to schedule something for Wed/Thurs (Simon: Wed possible, Thurs/Fri preferred)

Mac builder failures

• jdm: we have been seeing mac builder failures on changesets that should not call them. Mainly timeouts in the contenttests. Only brson & jack have access to the builders. Should we try writing the harness in python instead to see if there's a Rust bug?
• jack: there is a Rust bug with stdrun. Was causing failures (race) when the process died quickly.
• jdm: Not using stdrun anymore, but still the same mechanisms under the hood. They did not magically fix it.
• pcwalton: acrichton does not know of any races in stdrun. We might be hitting different code paths, but it's tested in Rust. There are scheduling bugs in Rust, but not related to it.
• jack: Can get you releng access (need your ssh key). Happy to hear other ideas for how to figure out what's causing this.
• jdm: I'll just try a python rewrite to get a new data point?
• pcwalton: Sure. Just logging into the bot and trying to reproduce it would help diagnosis, but the python approach seems reasonable.
• jack: I'll try to reproduce it on a builder while you rewrite it, and hopefully we find a real solution.

Priorities

• jack: come up with ideas in these areas (layout/contents/graphics/arch) and add to the lists?
• kmc: maybe the list on the wiki? Order it? https://github.com/mozilla/servo/wiki/Version-0.1 https://github.com/mozilla/servo/wiki/Roadmap
• pcwalton: 0.1 is basically right. DLBI needs to be incremental reflow (as we saw when kmc started working on it). So, put incremental reflow there and we're pretty set. DLBI will come after / with it.
• kmc: Missing piece is reusing the render tree.
• pcwalton: Incremental box building is by far the most important thing that we need. The overarching goal of 0.1 should be demonstrating the feasibility of servo. By showing it's a full proof of concept. Needs to be convincing, so need to have all of the "bits" of other browsers working kind of OK. With reflow speed we're seeing, pretty excited - there is promise. Shows Rust can be fast enough, definitely.
• pcwalton: maybe de-emphasize embedding api?
• jack: missing stuff from the summit feedback (inlining C++ to deal with SpiderMonkey, content stuff?)
• pcwalton: demonstrating feasibility
• dherman: Lots of ways to define feasibility. What is yours?
• pcwalton: inlining?
• jdm: SpiderMonkey is built to support inlining, and our C wrappers will break and possibly destroy JavaScript performance.
• jack: memory management is complicated. If we have to duplicate it with C/Rust, it will diverge from their plans. Very few SpiderMonkey engineers thing anybody should touch the memory bits ever. Set off by our tracehooks for proxy classes, which they had removed. They did not want to put them back in. Concerned that we duplicate all this code in Rust and that it's not a scalable strategy. Leading strategy is to compile SpiderMoneky with LLVM and inline it with Rust.
• pcwalton: orthogonal to trace hooks issue. If that's true, then we should push it on the Rust side, if necessary. If there's a concern that Rust doesn't inline enough, the fact that our reflow is 20-70% better than the competition destroys that w.r.t. C/C++.
• jack: More concerned about getting this memory boundary stuff wrong, which is more likely if we duplicate the code (or there is divergance).
• jack: single inheritence for managing the DOM as well. Need to make it so we can write these DOM bindings without a lot of pain. They're not super-fun right now.
• pcwalton: Yes, definitely. Again a Rust issue.
• kmc: Concur. Worried about not having a good solution to that and need one from the Rust side.
• pcwalton: All very good things.
• jack: Graphics. Need solution to multi-process. Know pcwalton is working on that.
• pcwalton: Trying to get that up today!
• jack: First milestone on that is just getting the compositor off in its own process. Can spread the rest of the tasks later. Just one out gets us split up.
• pcwalton: Noticing many of our messages are questionable and need refactoring for multi-process. Probably just a day or so of work to clean them.
• pcwalton: In terms of reflow, just need to show that since we already show good performance, getting incremental and CSS selector matching would help with demonstrating good perf. Based on the data we have, it's not that difficult once the algorithms are in place.
• jack: Our perf & sec. vuln. story is strong. How are we going to demonstrate the feasibility of parallelism? Need selector matching parallel; layout parallel?
• simonsapin: increment reflow only for first? Or for modifications from javascript as well?
• pcwalton: all in one unified framework
• simonsapin: do we have enough of the DOM in place to test it?
• pcwalton: yes
• pcwalton: for parallelism, CSS is parallelized (samsung landed it). On an 8 core, we're still 12-13x slower than gecko b/c we don't intern strings. We need concurrent hash map for that to work. Seo had a good suggestion (optimistic cuckoo hashing). Parallel layout, this is the Big Thing, possibly most important open question we're tackling. Need Chase-Lev Deque. Those are high-priority, but hard. Need to implement the traversals in parallel (non-trivial, though easier). Layout is set up to be parallelized. Once we have the data structures, pretty set. That's important to find out how much it'll buy us. Another possibility is just divide-evenly w/o deques (partition the work evenly).
• jack: is there a middle ground?
• pcwalton: could lock on the deque.
• kmc: Should be a pluggable thing to switch to chase-lev deque...
• pcwalton: Can switch when we it's available. Then could focus on the traversals.
• jack: If the rust scheduler's already doing this, couldn't we use it for us?
• pcwalton: tasks are used in the scheduler. switching tasks is probably going to be too expensive (register switching). Margaret showed task-per-node did not work well. Need better division of work as partitioned data, not tasks or you suffer from granularity.
• kmc: lighter abstraction than task from Rust that would help us?
• pcwalton: would be great if there was a lighter-weigh task for this. problem is that tasks have a stack.
• kmc: work-stealing units could be uninterruptable tasks...
• pcwalton: yeah, then run them on the same stack. Would be reasonable.
• kmc: Could have a Rust scheduler for running those tasks.
• brson: a work-stealing abstraction we could share with Rust would be great. The rust scheduler does a lot of stuff servo doesn't need.
• jack: is the current work-stealing stuff that it does available?
• brson: there's a paper. It's just the basic work-stealing algorithm. the data structure is the hard stuff.
• jack: is it easier to implement the rust data structure?
• brson: Sure, you can definitely steal that.
• jack: Let's steal the rust deque, implement our own work-stealing, and use that as our starting point for the traversal. Optimize the pieces as we go along. Good for a first cut?
• kmc: I'd be interested in cuckoo hash table for interning and can do it right now. Priority of that vs. rustpkg work.
• pcwalton: how much is left on rustpkg?
• kmc: Idea was that servo would force rustpkg to be done would help rustpkg be ready for release.
• jack: Most of the time has been spent on Rust upgrades to get new rustpkg updates. Generally 1.5 hours to find the next problem, then a few multi-day to week Rust<->Servo updates and bugfixes. The delay isn't rustpkg. And it really isn't that important for servo.
• pcwalton: less flaky builds would help. A two week Rust upgrade is tough.
• kmc: Did we just get the easy subset of dependencies?
• jack: Yes, it's everything with pure Rust, no dependencies or depndent on rust packages. Next is rust-cocoa, etc. with single C files. Then, stuff like rust-cssparser that has a prebuild step where it has to do something before it can build because it generates source files.
• simonsapin: Needs a way to have rust code generated by running some other code. Not necessarily a previous step...
• jack: rustpkg supposedly supports this now. I did the Rust upgrade. Haven't gotten back to it yet. Not sure what to do, because it will bitrot otherwise. Would be nice for somebody else to look at it instead.
• pcwalton: Can we just land it?
• jack: I think kmc's looking at it
• pcwalton: Then let's push it and get it in.
• kmc: Last week was a Rust upgrade. Could push the stuff you alredy migrated and land it here.
• jack: brson, having to upgrade Rust to get new rustpkg features is causing a lot of delay. Is there a way to spin it independently?
• brson: Could backport rustpkg and let you have the revision you're using.
• jack: Could we just split rustpkg out / duplicate it? Is it standalone?
• pcwalton: the problem is Rust's level of churn. Need to start deciding on unwrap vs. get, stop changing stuff.
• jack: Not as big of a problem; they were mechanical. This time was strcat's change where enums got compressed into the smallest possible type. Burned us badly. Bugs in it, and then when we got those fixes, the new Rust that had also landed had more bugs. Not sure how we could change that. API changes are really not that bad for us.
• kmc: The enum change broke code relying on the layout of structures?
• jack: Internal rust bug with destructors.
• kmc: can we be more robust to Rust changes? More asserts, etc? But if it's mainly Rust bugs, nothing we can do to help.
• jack: parallel, content important. Graphics under control. Anything else?
• pcwalton: embedding thing. Maybe over-emphasized? Have proof-of-concept webkit thing.
• jack: these 0.1 were joint Samsung/us, and embedding mattered more to them.
• pcwalton: I think we can duplicate the minibrowser/webkit API. Though if everybody's moving to blink, maybe that's more important anyway. There are zero windows users of webkit now. When do we want to have a browser people can download and play with. Right now, it's not impressive enough.
• dherman: in 2015, critical to have a pretty visual design with minimal chrome and a browser that feels like the new, lean, disruptive hotness. in 2014, just something for the bleeding-edge people to play with. Fine for a 0.3/0.4 mid-2014 thing. Good for the group to have something we can fire up, though there's already something we have.
• pcwalton: doing the exercise helped us find stuff we need to do (e.g., stopping polling the event loop)
• jack: definitely not as high-priority as the layout stuff. Probably a low-priority task until it gets done. Resize, etc. from the shell has found a lot of problems. Also, at the layout/graphics workweek for layout features, dbaron and others mentioned tables but a lot about flexbox. It may be the more interesting thing for us to try. That's my vote for going forward on features. Not super-enthusiastic about going acid2; acid3; etc. More interested in flexbox, tables, etc. In the near-term, pick one of tables or flexbox for layout features. Lot of talk about CSS transitions & web animations. Google is going to rewrite their CSS transitions code to be on top of web animations, which is probably a good approach for us as well. Several intern descriptions about CSS transitions; change to web animations.
• pcwalton: need incremental box building before any of this (layout/reflow)
• jack: any other things? layout & content seem the biggest ones. graphics and shell seem pretty established now. The last hard thing on graphics is GPU scheduling, but that's a problem for everybody.
• pcwalton: some crashes and races left. Somebody should dive in. Multi-process will probably fix it. But there are some other races during resize, which is scary. Our GPU rendering is also not fully baked. Has issues with way too many GL resouces all the time.
• kmc: memory leaks. and OpenGL capabilities Nvidia does not support. Bugfixes and making things more portable, but nothing huge.
• pcwalton: Shown our graphics architecture is viable. Similar to what Gecko uses anyway (but cleaner).
• kmc: Dovetails with gradients; do layered gradients on the GPU for content.
• jack: Everything in the compositor is a texture/surface. And we don't use any GPU skia stuff except creating the drawtarget, so we've abstracted both sides, allowing us to mix them.
• pcwalton: and move to D3D without any servo changes. Just change to rust-layers.
• jack: gecko uses ANGLE for something? Bootstrap windows?
• pcwalton: rendergl is like 500 lines.
• kmc: linux OSX have their own ideas of passing surfaces to the card
• jack: bas will know the answer... been avoiding it because it doesn't seem that important. Another platform is hard - we barely maintain Android.
• kmc: An intern would be nice, but it's sure to bitrot.
• jack: Yeah, until we are sure we want to support Windows, we shouldn't even trial port it.
• kmc: Should keep Windows in mind for multi-process, sandboxing, etc.
• jack: we can ask the graphics team for anything we should be on the watch for. They reviewed it all and it seemed fine for now.
• jack: I'll try to beef up the wiki pages for this week. You guys should think about what kinds of stuff you want to work on over the near term. Samsung probably has stuff they're interested in.