Meeting 2015 06 15

Agenda items

• Training materials status, call for help this week (larsberg)
• Research assistants starting this and next week! (larsberg)
• homu all the things (jack)
• resurrecting sandboxing (pcwalton)

Attending

• jack, larsberg, mbrubeck, simonsapin, pcwalton, manish, ms2ger (partial)

Training material

• larsberg: pnkfelix is working on the Rust training. He is about 25% done and we have some testers walking through it. I've started outlining the Servo training. I'll probably be contacting some of you this week to go over specific sections, talk about exercises for things like layout, DOM, etc. The trainings are next week at Whistler so we need to finish the material this week. I'll be talking about it at today's Mozilla project meeting. We have 45 people signed up. According to the work week organizers we have room for 100. I'm pushing people to sign up so we can start looking for a bigger room if needed.
• SimonSapin: Should we sign up too?
• larsberg: It'd probably help just for tracking headcount.
• jack: Just check the box?
• larsberg: Yes.
• jack: Is Conor working through the Rust tutorials?
• larsberg: Yes, and I also plan to ask him to try the Servo tutorials.

Research Assistants

• larsberg: Conor is starting this week and Laleh is starting next week. They both should be at Whistler, visas allowing.

Homu

• jack: I'm upgrading all our repos to use Homu. It integrates with Travis, which we'll continue to use for CI except on the main Servo repo. Saltfs, html5ever, rust-geom, rust-layers are already converted. If you find a pull request on a repo that isn't converted, don't merge it manually - we should add the repo to Homu and then r+. Seems to be working pretty well. The fact that it has Travis CI integration built in makes it really easy. The only tedious part is setting it up for a new repo. The setup is documented in the saltfs wiki: https://github.com/servo/saltfs/wiki/Adding-a-repo-to-Homu

SpiderMonkey upgrade

• jack: What is the SM upgrade status?
• larsberg: It's ready to go. It passes all tests now. I was testing on the builders last night. There are a few pieces of feedback from jdm that are bigger ticket items, which we'll file as follow-up issues and fix them after landing.
• Ms2ger: still 9 open issues on Critic too.

e10s

• pcwalton:I want to start resurrecting the multiprocess sandbox soon. Expect churn. I assume the SpiderMonkey upgrade should land first.
• jack: For sandboxing, does somebody need to review gaol?
• pcwalton: kmc and zwarich reviewed that already.
• jack: Does it need a Rust upgrade?
• pcwalton: For sure.
• jack: There was some issue about making things sendable, right?
• pcwalton: There were perf issues with serializing the display list. I'm just going to land it behind a flag and it will be slow for now. Eventually we'll want to use shared memory to have an untrusted allocator. I haven't written it yet but I have an idea how to do it.
• jack: Can we use k-dbus on Linux to send messages cross-process without copying, in a tamper-proof way?
• pcwalton: I thought that still did copying.
• jack: I don't think so, since it's used for audio now.
• pcwalton: There are a lot of good ways to do this for raw bits like audio, but harder for complex structures. I can see how to make it work, but it's non-trivial. But this doesn't block landing, since we can just rely on slow serialization.
• jack: What do Chrome and Firefox do?
• pcwalton: Firefox does painting in the content process, and then uses GPU sharing to share it to the chrome process. Which is great, but I think we'll get dinged for security relative to chrome if we do that, because it requires content process access to the GPU. Chrome uses Skia draw recording to send Skia pictures across the wire, which is great as far as it goes, but I think we can do better if we actually send display lists.
• jack: That sounds just as bad as our "slow" display list implementation.
• pcwalton: Yeah, they've had exactly this issue. And starting with Skia pictures (really low level drawing commands) is a disadvantage. To really compress the data you want to send high-level CSS-style properties, like "border with these properties", not "draw this bezier path".
• mbrubeck: Chrome also does something different on android. Think it draws directly from the content process.
• pcwalton: I wasn't aware of that! It does have the problem of either not using the GPU or if you do, you have to expose it to the content process and opens security holes relative to Chromium. Sort of a dead-end path. The untrusted allocator for display lists is the only solution I can think of with no downsides, provided the allocator is fast enough and you can make it zero-copy.
• jack: Landing in the slow path is fine in the first step, then.
• pcwalton: Also need constellation/pipeline script interactions working across processes, etc.
• jack: This is probably a Q3 thing, given we're a week away from Whistler right now.
• pcwalton: WIll try to get it in for the quarter b/c it's on the quarterly goals...
• jack: Then just wait for the sm upgrade and then have at it.
• mbrubeck: Found the reference, though it's kinda old: http://dev.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome Uses a GPU thread on android instead of a separate process. The GPU access is then in the main process, not the content process.
• pcwalton: I think they're changing that? That's what I gathered from roc's BlinkOn report.