Mozlando SM Servo

SM update process and speeding it up (till)

• till: Start up with a SM 39-ish timeframe from michaelwu w/ patches that get it to compile successfully
• till: can we upstream the landing of the bindings? We landed the LLVM-required patching for rust-bindgen. Would let
• sfink: could we do a test compile against the bindings in automation?
• till: we'd need to get rust running in the test infra on try; then we could test it there, too
• sstangl: scope of changes to upstream SM?
• till: Simplifying a few template usages that the bindings generator doesn't understand. Special doc comments for the bindings generator, too. Few small things.
• terrence: as long as there's a rust shell, then we can run the JIT tests against it. C++ shell is short enough that we could use rust
• till: next steps are the next SM update & then the patches and add open bugs on upstreaming the ones needed

till: Promises

• till: implemented in SM, but not landed yet. want to pull out into SM for Servo. Not ready for review yet.
• till: Gecko integration far from trivial because of devtools work.
• eddy bruel: If we move promises to SM, what about microtasks?
• till: still in gecko; just a JS_Callable. Should talk about exposing this not just as APIs

Access to strings inside ropes (mwu)

• mwu: I want a JS api to access the strings that comprise a rope to iterate over them without copying to a new buffer.
• jorendorff: Why? Doable, but... why?
• mwu: Want to access the data w/o copying. Don't want to linearize the string.
• nbp: Was requested by bz and roc before... (june 2013)

String representations (ajeffrey?)

• ajeffrey: USC2 & UTF8 is annoying . Would be nice if there were ways to know if a Latin1 is ascii...
• terrence: Do we know that?
• jandem: I don't think so. Run through the entire string to check. Could maybe add another flag.
• larsberg: Open a bug? (cc jandem)
• Ms2ger: Are there a lot of Latin-1 that are non-ascii?
• nox: Do people use Latin1?
• jimb: nothing is exposed! There are just optimizations. If we changed to optimized for ascii vs. latin1, I don't think we'd know that.
• jandem: Should be easy enough to add telemenry

Improving shims for hooking to either Servo or Gecko SM (bholley?)

• bholley: Currently gecko-servo-frankenbuild has two copies of SM. This does not work well. Had to remove SM from the Servo build, hack symbols, etc. This is super annoying! Would love to make it possible to keep them in sync, have mozjs be smarter about it.
• Ms2ger: We should update SM more often.
• till: Idea is if we have the m-c build generate the bindings we need in Servo, then we'd be able to update earlier.
• shu: Can you upload all the patches?
• till: Yes.
• shu: Can you just build servo given a checkout of central?
• jack: We'd like m-c to publish the bits. Splicing in a random C directory is rough. If you publish to cargo.io...
• bholley: Could do it for nightly.
• jack: You can bump the version number every day.
• mbrubeck: Should talk to them...they archive every version forever every day.
• terrence: Just need to have the integration do all this for us. We need to do this standalone work anyway for other customers.

nox: What's the status of WebIDL's [Unscopeable] attribute?

• jorendorff: not supported yet, I'm working on it next week! bz wants it too.

nox: JS_DefineProperties-like functions tailored for a Rust usage (no zero-filled entry at the end of arrays)

• froydnj: This would be useful for Gecko itself too, depending on how the API was designed.
• nox: Is this just for the JIT compiler? Maybe a version with pointers and length so that we can just use slices from the Servo side?
• efaust: no magic here.
• nox: I looked at the code, and it looked magic.
• till: Yeah, no magic here.
• nox: Can we just loop over JS_DefineProperty?
• efaust: Yes.

Magic DOM status (mwu?)

• https://github.com/michaelwu/servo/blob/magic/components/script/dom/bindings/magic.md

• related, self-hosted DOM: https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/3AdzBtlq0sQ

• mwu: Basically, we're working on a way to reserve slots in your class and define types on them so you can work against them as if it's a native slot but stored in the JS slots.

• nox: Does the GC move objects?

• mwu: More does get GC'd and can be moved, yes.

• nox: Lots more moves - pinned in Rust and never copied.

• mwu: The conversion is cheap for all types but strings. When you move things into Rust, this is why I wanted iterators earlier so you could avoid the string penalties. Since you know what type is inside, it's easier.

• manish: Do we need to have more invariants around not taking a reference to a slot in a JS object.

• mwu: Can't in any system where JS objects can be moved.

• manish: So we can't take a pointer to a value in a JS object and trigger a GC... hard to statically check.

• mwu: You can't take pointers to those fields in the first place... directly :-)

Rooting

• shu: Can you explain how rooting works? Why doesn't the C++ RAII thing work? What's up with walking vectors?
• mwu: Probably requires a 1:1 talk.
• shu: At a high level, how should rooting work?
• mwu: Every DOM object is marked something that says it has to be rooted. Also have Root objects that
• manish: Two types of pointers. One is a JSPointer, which is for use inside DOM structs. You can have those inside of JS objects. The other kind is a Root, which can be held on the stack. Those are temporary and follow RAII like normal C++ stuff and enforced by lints.
• shu: What's the discipline?
• manish: It's stuck to the stack.
• shu: Pass as an argument?
• manish: Fine! But you can't move it in Rust parlance (or return it).
• nox: In Servo, it's not explicitly a linked list on the stack; we just have the list in the stack when the frame ends.
• shu: Comes down to moves?
• nox: Yes.
• terrence: More like C++ persistent rooted, in that it's not an ordered stack-y thing with explicit order?
• manish: Yes. But Rust doesn't let you return it out of the stack scope.
• jimb: How is that ensured?
• ms2ger: You can return a root now, but the lifetime is still tracked.
• terrence: Full search to remove one?
• mwu: Search is backwards, so typically easy to hit.
• nox: Could reuse the LLVM machinery for unwinding to know at compile-time where the roots are and generate code to use this.
• manish: We might be able to do it via Rust GC stuff ( as a plugin).
• nmatsakis: We've been looking into support for this on the Rust side, pnkfelix has been looking into it, probably in a focused meeting.
• ajeffrey: Slight pain point from the vector. Any code that creates or destroys a root has to touch vector code. Not a problem for runtime, but bloats any code that creates or destroys roots, and it breaks inlining. It would be nice to keep stuff on the stack so that could be removed.
• mwu: Everything is inlined with self-hosted DOM
• terrence: Same problem with HashMap. That's why the stack is nice - two-line swap C pointer update. Usually on the same cache line.
• ajeffrey: LLVM would probably be able to optimize it better.
• terrence: Definitely see any extra instructions in our code output.

jemalloc

• ajeffrey: At the moment... lots of them.
• mwu: Have to hook SM into Rust's allocator.
• terrence: We valloc 1MB chunks. jemalloc also does that, so things work well. Only thing we care about from the allocator.
• ajeffrey: Easier to replace SM's jemalloc...
• mwu: glandium is the one who said that, and it's right because otherwise the linking stuff won't work right, especially on OSX
• bholley: Doesn't realloc everything?
• terrence: Smarter for strings and slots on objects.
• ms2ger: Rust just uses jemalloc.
• terrence: Lots and lots of tuning in SM. There are some issues around heap fragmentation. There's also about:memory, which needs to know how to measure the actual allocated memory.
• bholley: If it's really tuned...
• terrence: Not terrible performance, just bad heap fragmentation. As long as you are aligned to 1MB allocations, SM will do the right things.