Meeting 2014 08 11

Agenda

• Q3/Q4 work week ( https://doodle.com/xv3nk2d589k2zgcc )
• Hi-pri Rust issues: https://github.com/servo/servo/issues/2853 (larsberg)
• Memory usage update: still bad, even after upgrade w/ lifetime fixes (larsberg)

Attending

• jack
• larsberg
• Ms2ger
• Manishearth
• laleh
• zwarich
• azita
• mbrubeck
• SimonSapin

Workweek

• jack: Sent out the poll for a workweek. We have budget for a workweek for Servo again. It's unclear how much we can do for Servo at the all-Mozilla workweek in December, so we thought it might be a good idea to revive our cancelled workweek plan. The original ones we decided upon are too early for approved travel.
• simonsapin: Is the week of October 20th not an option?
• jack: I'd only be able to be there a short amount of the time - I'd be double-booked. We'd also have to have it in SF, which would be really expensive. Owait, no, ALBQ.
• azita: The SF option in the last check I did, it depends. In the last budget check with travel, it seemed to be about the same as Mountain View and Portland. I don't think it's too much more.
• jack: But in Portland, we spent 300/400 per person less and had a lot more events.
• azita: If half the team is here in SF and they go home, it all turns out to be the same. Just as an option.
• jack: Please vote soon! We have to decide quickly,

Rust hi-pri bugs

• larsberg: We're down to two right now. The macros/hygiene one blocking the HTML parser is still outstanding; Felix working on it. The other one doesn't have anyone assigned yet; I'll ask brson about that.
• jack: Is this the segfault we just found in opt builds?
• larsberg: Yes.
• jack: For anyone who missed it, we landed the Rust upgrade with a simple workaround for that bug but we still don't understand the underlying bug. If you see mysterious segfaults in opt builds, ping me or larsberg.
• jack: There was another one Luqman did from the last upgrade which finally landed over the weekend.

Memory issues

• larsberg: I measured again this morning. Good news: the rust upgrade landed with a fix for stack lifetimes. Bad news: We still have a problem with big stacks. There must be some native thread that's causing a bunch of trouble. pcwalton: We may not be lazily mapping stack segments. So the OS is giving us a big segment it's counting against our memory usage. I should point out there's work being done by a community member to make Rust use guard pages instead of the current stack checks, which means that if you run out of stack in a C function we would now correctly detect that and fail more gracefully than the explosion that currently happens. I believe in Servo if you set small stacks then the JS engine will fail in mysterious ways.
• jack: Previously we suspected the JS engine was the culprit because of the way it migrated between green threads. But I believe jdm and Ms2ger committed something that pins it to a task.
• zwarich: Did that get landed?
• Ms2ger on IRC): Not yet. Linker issues.
• larsberg: I'm suspicious because if you measure memory usage just after initial render, then again after something like a resize, the memory usage explodes.
• pcwalton: We should try just passing the flags to reduce stack size.
• zwarich: I'm not sure how larsberg is measuring stack space, but it seemed njn was only measuring resident pages, not mapped ones. So I'm not sure reducing the stack size will help, if we're actually using all that space.
• pcwalton: If we're using massive amounts of stack space then it should be fairly straightforward to track down.

Some other patches

• jack: I have a stack of patches I've been working on between Rust upgrades. I'm curious what people want me to work on most. Currently I'm working on 32-bit builds. The other thing I'm trying to do is get bors redone for our new Travis workflow. Also working on mach/cargo integration. Any opinions?
• pcwalton: I like the idea of using cargo since our contract is coming up.
• Manishearth: Anything I can help with on bors?
• jack: I'll send you my bors stuff and I'll move ahead on cargo.

Workweek (2)

• Simonsapin: location?
• jack: No plans yet, except not Portland :-)
• Simonsapin: But likely US?
• jack: Yes. Getting tired of coming here?
• Simonsapin: No, I have another trip at the end of October, so it would be ideal to just extend that.
• azita: Does that mean the November week is better for you?
• Simonsapin: Yes. W3C TPAC is the week of Oct 27 (in Santa Clara).
• jack: I think you and jdm and myself travel the most. Hopefully between us we can find something that works for everybody.

Gamedev

• jack: I also noticed Piston did a freetype binding that's way better than ours. Not just the FFI calls - they have modules for glyphs, etc. If anyone is going to be doing font stuff in the near future, we might want to port to the better binding and retire rust-freetype.
• pcwalton: Sounds great!

Android

• jack: Has anyone got Android working with the new upgrade?
• mbrubeck: I built it on Thursday or Friday on the Rust upgrade branch just before it landed and it was fine then. I'll look again.
• pcwalton: laleh said we're still 4-5x slower than Firefox. Turn it off?
• jack: Sounds good to me.
• pcwalton: Yeah, I think layout logging is probably killing us.
• jack: Should try it and see, then PR it.
• larsberg: Was just on because Android was always broken. I'd be fine turning it off.
• jack: I tried hard not to break Android this time.
• jack: What's up with random killing?
• manishearth: There's a time limit (10 minutes) without any output and then it gets killed... script is probably hitting it.
• jack: It shouldn't ever take 10 minutes to compile a servo crate, right?
• zwarich: We could test it by logging times for when it starts logging crates.
• manishearth: I think it already has timestamps per line... (nope)
• jack: We can turn logging of codegen on in rustc.
• pcwalton: -Z time-passes, too.
• jack: Would be nice if we could debug this with their help; are they back from their workweek?
• larsberg: I believe the Travis team is supposed to be back this week.

Parallel builds

• jack: Splitting up the build into multiple sessions seems to take longer - Travis would run the first three, then the next three, etc.
• manish: Travis throttles, especially for OSX, where you don't get all the VMs at once. Even if you have 10 commits, it'll only allocate VMs sequentially. I don't know the exact logistics behind it, though.
• jack: Should we do less splitting? Just w-p-t separately?
• manish: That should work.
• jack: I assume the w-p-t is the thing that takes us over the limit.
• manish: Yes, when Ms2ger enabled HTML tests, it went way over. Didn't even get to halfway.
• simonsapin: Can we get more allocated VMs?
• jack: I think that was on the list of our travis requests before. Maybe try switching it so we get more builds? That would make it faster. Adding Android and a 32-bit target would be additional ones already...