Meeting 2015 03 02

Servo Meeting 2015-03-02

Agenda items

• Good first layout issues (jdm)
• Memory leaks (jack)
• Recruiting (larsberg)

Attending

gw, jack, kmc, larsberg, mbrubeck, pcwalton, jdm, Manishearth, Samsung, brson, azita

Good first layout issues

• jack: There are some people interested in getting started in layout, but there are no E-Easy bugs for it. pcwalton and I have talked about possibly leaving some of the CSS transforms undone? Some of them seem easy to make good first layout bugs because they have some values for the property implemented, but not others. People can learn from the code that already exists.
• pcwalton: CSS transitions. I have an old branch that has support for that and I'll try to get it landed.
• jack: OK, we can do that and then see which transitions need to be landed.
• pcwalton: Once my layout changes (4) land, feel free to rustup again. A couple of them have gone through several rounds of review.
• mbrubeck: Another source of easy layout issues is that there are over 100 FIXME comments in the layout crate. Some of them are hard, but many are potential optimizations, edge cases, missing features, etc. I can go in and try to look through some of those, but pcwalton wrote most of the comments and might have ideas.
• kmc: What about going through disabled ref tests to see which ones now work and which could be fixed easily?
• jack: How many?
• gw: 4-5.
• kmc: Yeah, and iframes, too.
• gw: Now that our Linux tests don't rely on X, maybe they will "just work."
• pcwalton: One possibility is Canvas features. Though maybe it's accounted for?
• jack: We had a PR for something straightforward on Canvas.
• pcwalton: Those features are straightforward and fun.
• kmc: Not layout, but does address letting more websites work in Servo.
• pcwalton: One thing that would be extremely helpful is going to a broken website, finding out why it's broken, and create a minimized test case. We know there are issues on websites, but it takes time to create a test case. Like percentage widths on tables, it's usually a small fix, but minimizing and finding the bug and creating a test is hard.
• jdm: Lots of suggestions are around not touching the layout code right now. I'd like to explore people getting to touch layout code itself. It would be nice to have repositories of knowledge. 1) If a website looks wrong, how do you identify what is wrong, create a minimized test case, and fix it? 2) A PR example for how you create a new CSS property. These are the things people need to know to become useful in layout.
• gw: I could write a wiki page on how I work through a broken webpage, create a minimized case, etc.
• manish: Could do the same with canvas (writing a wiki page on it).
• jdm: Identifying good PRs that are models for specific types of work in layout are valuable. Also, triaging bugs in layout to get further work done on it would be good. That will make those bugs actionable to non-layout-experts.
• manish: And if you come across something you could fix in a small PR and it isn't blocking anything, you can always create an E-Easy issue for it instead.
• jdm: I'm a fan of file first / fix later.
• jack: We seem to have done a good job of it before in that when we add a new feature in layout we just implement the portion of the spec that we needed. We do not do a good job of documenting the parts that we have not done. It would save us a lot of time and help onboard us if we could do something like the giant metabug that jdm opened with all of the individual steps required.
• pcwalton: It also doesn't help that most layout code was written under time duress to get ACID1, ACID2, or the static suite working.
• jdm: That's how we fix that problem!
• gw: I'll start with the wiki page on "intro to fixing layout issues."
• pcwalton: I'd be happy to collaborate.
• gw: I'll start and send out a link.
• jdm: If I spent some time going through old layout bugs and flagging ones that look like they might be actionable. How can I get people's attention that won't fall through the cracks?
• jack: e-mail?
• pcwalton: assign bugs?
• larsberg: Layout is super under the gun in terms of reviews and features to fix up. I'd just make sure that if you open them up, particularly right near the end of Q1, you will run into the writing modes & fragmentation work that are going to slam the layout people.
• jack: Hopefully good first layout bugs are easy to review.
• pcwalton: Yeah, if it's short and has a good reftest. Most layout bugs are either a giant piece of missing functionality or a 5 line feature.
• jack: Also, need to onboard people or we will continue being slammed.

Memory leaks

• jack: I've been tracking down leaks in https://github.com/servo/servo/issues/4915. Stack traces with various memory leaks. The first one is in the computed style cache - Arcs of computed styles that we hand out to layout things. Some of them don't get freed, and I haven't been able to figure out why. The second one is a vector of line breakers that doesn't get freed. There's no reason this should be leaking, unless there's a bug in the compiler.
• pcwalton: I heard there's a really nasty one where sometimes variables leak. Don't know many details, don't know if anyone's working on it.
• jack: I'll ask around.
• pcwalton: Worth doing; I wouldn't count on that being it, but it's worth looking into.
• mbrubeck: I was looking at the code for the Arc layoutdata. It's one where we create it on the layout thread and hand it to script and then when we shut down that pipeline we send a whole bunch of messages back to layout to deallocate it. Then, we send an exit message.
• pcwalton: Why do we have to deallocate these things on the same thread?
• jdm: The types are different.
• pcwalton: Script could call through some trait object to some real type and drop it on the scrip thread...
• kmc: Inherited from managed boxes?
• mbrubeck: Very leak-prone now because it depends on message ordering. There are other ways that layout can exit (e.g., if a child task fails).
• pcwalton: Seems like it would be nice for the script task to free things.
• jack: I put in tracking messages. We are doing a massive number of reflows. Savago has been looking into that. If you load one of them, layout data never gets removed until the page is destroyed or you hit escape.
• mbrubeck: That's how it's designed...
• jack: If that's how data should be reaped, we should do it at reflow.
• gw: The data structure that reap_layout_data cleans up is allocated once per node. If the node continues to exist, there's no reason to be reaping.
• pcwalton: Important for incremental layout that it stays around.
• jack: Where else would be put these computed styles? Applied styles cache is one place it goes to. There's nowhere unsafe, right?
• pcwalton: Maybe that cache has sketchy thread-local stuff... we've had issues where that isn't properly cleaned up.
• gw: Definitely thread-local. I changed it a while ago (after we went off green threads) to the normal TLS stuff. Will be kept around on each of the layout worker threads. If it's just 32 per thread, it shouldn't explain the leaks.
• pcwalton: Can also just comment out the cache and see if that gets rid of the leak.
• kmc: Also capture a backtrace when the refcount goes above a level.
• jack: That's the next step. First thing I did was add Drop to ComputedValue and there are a ton that get deallocated. So some of them get deallocated. Also added debugging for when they are added to the cache, and it seems to be working correctly because things going into the cache did get deallocated eventually. I'll keep looking. Also, there are 2-3 more stack traces I need to look at. Vec::push is two or three of them.
• pcwalton: Probably a bug in the container of the vector not releasing the vector properly. Valgrind would have caught it.
• brson: We don't run valgrind on Rust.

Recruiting

• larsberg: Positions are opening this week! Be ready to actually ask people to apply.
• azita: Any interns this summer?
• jack: 0 for Servo, but two coming in through the researcher program (more flexible internship program). One coming for mobile power usage, another coming for scheduling algorithm stuff. Scheduling network requests, work stealing, etc. All slots are accounted for between Rust and other projects, but there are five or eight slots for researcher things still available, so if you know someone who wants to work on these things for ~3 months this summer and would work well remotely, we should talk to them. Since mentor is remote, need to be sure that candidates have good communication skills.
• jack: What are our chances on GSoC?
• jdm: It looks like we were not accepted, for the first time ever. Also Linux Foundation and Tor.
• jack: We do have bandwidth and some funds available for some stuff. If we know people who were going to apply to GSoC and looked like good fits to be successful remotely, let us know and we can check it out.
• jdm: There's another similar program that goes year-round in chunks. "VALS semester of code?" It has more academic tie-in with an academic faculty member, etc. There was interest in the WebGL canvas there.
• jack: NCSU?
• jdm: They're doing the class again right now! Two projects.
• jack: Which ones?
• jdm: WebSockets and more dev tools. Hopefully network request logging.
• jack: Timeline view would make me very happy!