Whistler FFOS

Agenda

• Sony Z3C support
• Gaia V3 arch changes
• Security model
• Raw Rust vs. other hosting API support

TODOs

Maybe meet with the SM team more with mwu and pcwalton on more exact rooting and the DOM-in-JS direction work.

Sony Z3C

• larsberg: What is missing?
• mwu: Should just work, except for the audio stuff. May need to rewrite some of the h/w integration features for things like touch events.

Gaia V3 architecture stuff

• gabriele: new gaia architecture changes are about separating frontend & backend (leverages serviceworkers). Should have one behind each application for data-related stuff. How does manipulating the DOM from a non-domain thread work in Servo?
• larsberg: not allowed by spec
• gabriele: just want to be able to do some stuff like reflecting sizes
• pcwalton: can do in an iframe right now (if cross domain or sandboxes). Could extend to serviceworker. But, want to get buy-in from other browser vendors, etc. DOM in other threads is a major change
• gabriele: probably do just want a separate document in a thread; that's fine. Having different pages in each separate component in the apps is the new architectural design.
• jack: We like multiple sandboxed iframes.
• pcwalton: Can experiment with that right now to see if it works. Could even polyfill fake ServiceWorker as an iframe.
• gabriele: Good; still trying to get quad-core working a lot better. Constrained memory-wise, though.
• pcwalton: Memory bus is a bigger issue for us than total memory size right now in Servo, though of course there's still more stuff to tune.

Security model changes

• hylands: Customizer can inject stuff into running apps. Had to make changes to allow that to happen, turning off some of the security stuff to prevent that from happening.
• jack: Little bit scary...

Raw Rust vs. other hosting API

• mwu: Don't think CEF makes sense; there's tons of low-level things we only want to do on Gonk (e.g., hardware composition). Take the layer tree and figure out which are the biggest, send them to the h/w compositor, and that will come back and say that it can only do some of them and you have to do the rest. These low-level details only make sense on Gonk.
• pcwalton: Generally advocating getting rid of everything but CEF, but I am mainly concerned about navigation. For graphics, whatever unstable stuff is fine.
• jack: I don't think it makes sense for a Rust program to call the CEF C ABI then back to Rust!
• mwu: How much would we use? Gaia's going to hide everything. CEF makes no sense.
• pcwalton: Just use the simple "start a fullscreen browser."
• jack: Should just use a rust API.
• larsberg: We have one - the Browser interface!
• pcwalton: I just don't want two divergent APIs.
• larsberg: That's how it's all set up today.

Layers

• pcwalton: May want a layers backend for the h/w compositor. Much simpler! Only two operations right now.
• mwu: Superset of OpenGL compositing.
• pcwalton: Just add render_b2g.rs.
• jack: It's like 5-line shaders.
• mwu: Just bringing this up because it has to be done later, but not now.
• gabrielle: There are some layer workarounds in Gonk today...
• pcwalton: Android, too.
• mwu: Drivers are getting better over time. Gonk port also supports KitKat+. It's mainly G and I series that were bad. G was a total nightmare.

DOM stuff for speedups

• mwu: Want to implement "magic DOM objects." Today, DOM's simple like other browsers, but with more safety (because the reflector owns the DOM object). Otherwise, no significant improvements.
• mwu: I want to take the struct with the fields you want, wrap it in a magic macro that transforms the size of the DOM struct to zero. Then, the fields instead reach into the reflector and into the reserved slots, and BOOM!
• pcwalton: We called this "fused" DOM objects.
• mwu: That was in-place allocation of the structs. Different! This stores fields in the JS objects. You want to use that instead of native fields in the DOM object because if they're in the reserved slots you can configured the bindings to go to the slots. So, instead of going to native code, just grab straight from the slot.
• pcwalton: JIT?
• mwu: Yup, works automatically! The macros would map fields to indexes.
• jack: How does this relate to eager reflectors (like Servo) vs. lazy reflectors (like Gecko).
• till: Hugely important for memory usage...
• jack: True, but accessing them is super faster in Servo. So, if we do fused objects, can we still be lazy, or not?
• mwu: I don't see any wins with lazily doing it. You have to allocate them one way or another.
• jack: The Rust side, yes; but the DOM object maybe doesn't if you never touch it.
• mwu: OTOH, you remove the Rust allocation in the eager side!
• jack: Isn't the problem total memory usage?
• pcwalton: No, the cost of the reflector+DOM object was large. But, with "magic DOM objects" we remove the reflector part. You have a JS object, but just what was in the separate allocation.
• jack: Point is that the JS object in Gecko is never created!
• mwu: But you still create the C++ object in Gecko's case.
• pcwalton: Yes, for all things in the heap. You have to create them and keep them around for incremental layout.
• jack: We should have bz here.
• mwu: There's also a lot we can do to reduce the DOM memory in this approach by using indexes instead of pointer (reduces sizes significantly - by 3/4). Would only work for trees with < 64k nodes or so.
• gabrielle: Only Gaia applications where we run into that are the SMS app. Otherwise, they're pretty small. In the future, trying to move that stuff to virtual lists where the DOM is a subset of the data and remove/add as the user scrolls.
• till: Are these moveable?
• mwu: Yup, removes fragmentation issues.
• pcwalton: Fragmentation is huge. Should consider it for the frame tree, too. Layout is so memory bound right now that increasing our cache line density would help.
• jack: I like this idea a lot and would love to see you hack on it :-)

SM perf issues

• jack: One SM issue is that the checks are in headers...
• larsberg: We wrap them in C code.
• jack: Solution is supposedly to compile SM with clang.
• mwu: Aha! The inline functions in the JS APIs. I just rewrote them in Rust instead.
• jack: They didn't want us to do that...
• larsberg: So?
• pcwalton: YOLO
• mwu: What we're doing right now is dangerous and prone to breakage, but it is not crucially urgent.
• larsberg: The SM team has offered to let us land code upstream if we provide tests. There is enough Rust infra support there.
• pcwalton: I think the Rust team should work on this. But we're OK for now. And I'd feel great landing this stuff upstream.
• mwu: There's a lot we can do with the bindings generator.

Exact rooting and stack maps

• pcwalton: This landed in LLVM upstream.
• larsberg: pnkfelix is working on this right now.
• pcwalton: Removing all our roots is nice.
• mwu: But, with rooting being annoying helps to avoid it.
• pcwalton: We can make it no-op.

Layout problems in FFOS

• gabrielle: During startup, we modify the DOM, which we know we shouldn't. The dialer might be static, but we have to check for RTL language, which is too late. We're not just flipping things over - some things are reflected, but some are not. It's huge JS code poking to flip things around.
• jack: Why JS flipping?
• gabrielle: It sets CSS attributes. It causes all of the prior layout work to be wasted effort, which is what's terrible. E-mail is even worse. The search field appears above the e-mail list, but in the layout it's just part of the whole object. So, at startup, we read the element and shift it. But, in order to read it, layout must be finished; then we move it, scroll, and have to layout again. We have a lot of pain points in the layout engine.
• mwu: But Servo doesn't have getComputedStyle?
• pcwalton: Has getBoundingClientRect, which is enough. But, really, what would you like to be doing? How would you like this fixed if the magical layout engine help?
• jack: Start with it hidden?
• gabrielle: Breaks async pan/zoom.
• jack: If it's AZPC, we should just test it.
• pcwalton: We have a great solution! We ONLY are async, whereas gecko will turn off async for broken cases and work synchronously.
• gabrielle: For the RTL stuff, it has to be wholistic.
• jack: Why not just be setting things globally?
• gabrielle: Maybe. But this also happens if you have > 1 SIM in the phone. Again, happens at startup of an app after layout has already started.
• pcwalton: So, the issue is that if you have synchronous layout, you have script then layout starting (partial), then script runs and discovers something that causes it to switch to a different state. Servo can help change this by at least being concurrent and possibly kill the layout if it's useless.
• gabrielle: It's mainly if layout is interruptable or not.
• pcwalton: We're always async, which is basically interruptable (we could add it). During the first (useless) layout, script can't run in Gecko. It can in Servo.
• jack: The one thing you can't do is ask for properties, though.
• mwu: How does GBCR work?
• pcwalton: Sends a reflow and then blocks. Have talked about async GBCR.
• jack: Could return immediately, though we don't do that yet.
• pcwalton: Can use the ReflowGoal infra there. ForScript could be smarter. Could use that for prioritization & cut-off.
• gabrielle: Only parts are useless. Would be nice if we're just incremental.
• pcwalton: We don't have all of bz's incremental tricks.
• larsberg: We are parallel, which papers over a lot.
• gabrielle: Anyway, I think Gaia's a great test case for this stuff. All over the place from veteran web devs to last-minute contract deliverables.

Dealing with the DOM APIs in Gonk

• mwu: That's next.
• jack: What are the first things you'd add?
• mwu: Indexddb. Promises.
• pcwalton: document.write?
• gabrielle: No. It's forbidden.
• mwu: How do you not have it? Isn't it scary not to have it?
• jack: Infra is there; we just don't have it wired up.
• pcwalton: Also need OMT HTML parsing.
• jack: We can hire things that are self-contained if there's stuff that people will work on. If you have a short list, we can look for people. Contracting possible; hiring researchers possible; using NCSU possible.