Mozlando Servo MagicDOM

Overview

• https://gist.github.com/michaelwu/beec9e0a31d906da3d98

Outline of the basic idea

• Basic idea is to take advantage of reserved slots in JS objects.
• Is 16 slots enough for your purposes?
  • It might not be.
  • We can change it; just curious.
• We can create a special zero-sized object in Rust that is zero-sized, just accesses the fixed slots
  • Contains a lot of type information abuot the slot contents, statically checked.
    • don't need to tell the JS engine about what's in the slots
  • Can get rid of finalizers, store all information on the object.
• Interesting part is when we combine this with self-hosted JS code
  • In the JS engine there si code for various JS interfaces implemented entirely in JS
    • huge perf benefit for SpiderMonkey because of JIT optimization without special cases for native code
    • Some complicated rules for writing this code, but they could be enforced by a transpiler.
      • for example, can't just write a normal JS function; need to follow WebIDL rules about arg conversions
      • but since it's all in JS, the JIT can do things like lift these conversions out of loops, or eliminate them
    • Still have codegen, but it will be generating JS
    • Generated code can be friendly to type analysis because args will always be a particular type of object
  • I am creating a statically typed language that compiles to JS
    • can write self-hosted JS implementations safely
    • uses the Rust parser, looks like Rust syntax, simplified version of the language
      • Doesn't use the Rust type checker, only the parser
    • Could be converted into a Rust compiler plugin, so code can be inline in Servo DOM code.
  • jack: If we write DOM code in JS we can potentially share with Gecko for "free", but not with Magic DOM?
    • bz: Gecko would need to change its object layout, and also the Rust compiler plugin wouldn't work for Gecko
  • bz: How do you plan to handle cross-compartment wrappers?
    • are compartments only cross-process?
      • same-origin iframes are in the same process/runtime but separate compartments, unless sandboxed
    • mwu: I came across this problem with iframes. We might have specialized types to represent things that are wrapped.
      • If you try to assign something to a slot that belongs to another compartment, the JS engine gets angry
      • Better than what we have now using raw pointers that don't really assert anything.
      • Needs investigation
      • Related problem with proxies
        • bz: We will fix it to make it possible to have reserved slots in proxies.
        • mwu: Right now we re-wrap things
    • bz: I suspect that handling CCW in self-hosted DOM code is going to be quite painful.
  • bz: How do you handle CCW today? * jdm: We don't. And don't run with debug mozjs, so we don't get any assertions... * bz: You should start building with debug mozjs!
  • jorendorf: Handling x-ray, security checks, etc. for CCW is going to be complicated
    • bz: x-ray is used to handle DOM object / system code interactions
    • Can't let the page interfere with the object by messing with standard prototypes, etc.
    • till needs to solve some of this anyway, for Promises
    • bz: the hard thing here is that you can't do your slot accesses from the x-ray compartment.
    • mwu: As long as that get optimized out
    • bz: Can make a slot intrinsic that knows how to operate on x-rays
    • mwu: But everything is an x-ray?
    • bz: No, x-ray is only for going from more-privileged to less-privileged code.

Memory consumption

• bz: Are you targeting 32-bit as well as 64-bit?
  • Yes
• Besides pointers, can also play games with size of integer, boolean, etc.
• If you can make do with fewer slots, that's good.

Self-hosted code

• When doing self-hosted stuff, can you have a DOM interface that has some self-hosted methods and some native?
• I have an attribute to mark things self-hosted, can be per-method or whole-interface.
• When the JS runtime is created, self-hosted code is compiled into a separate compartment and then shared
• In all the actual content compartments you get lazy functions that are empty shells for the JS function
  • on first invocation they get cloned over from the self-hosted compartment. Then they operate as normal JS functions.
  • Normal JS functions except global name lookups aren't resolved on the normal global object.
• So if we're making an interface that requires queueing a task, that requires exposing an intrinsic?
  • Yes. Just requires exposing a function to SpiderMonkey.
• For self-hosted APIs, do we have a Rust object defined for the DOM struct? A JS object with fields and stuff?
  • mwu: Yes, that's all generated.
  • jdm: In the transpiled language, you use field names to access the data in the slots?
  • mwu: Yes.

jdm: Any heuristics for determining when self-hosted is better than native?

• mwu: If it doesn't have to interact in a difficult manner. Depends on how many other APIs we manage to implement in JS.
• Calls from JS to JS get a huge speedup.
• ajeffrey: Compile to both native rust and self-hosted from the same source code?
  • mwu: They're fairly different things. It might work in some cases. But there's no &T in this language, can't express Rust semantics.
    • No lifetimes, for example.
    • nmatsakis: Could just use local variables instead. References would be possibly unsafe anyway. Should not support & operator. Translate foo.x to copying the pointer out...
    • mbrubeck: The generated Rust code from this Rust plugin code is going to look very different
    • till: Yes, will not make sense to self-host everything
    • mwu: Usually obvious from what the data structures are. If you can store it all in slots, implement as self-hosted JS.
• mwu: Often is obvious based on whether the data structures you need fit in the slots.

jdm: Is magic DOM all-or-nothing? That is, for things mainly accessed in layout don't live in slots; others do?

• mwu: Yes. I put things that don't make sense in a reserved slot into the heap as an extra slot. I have objects that are heap-only like that.
• jdm: Introducing an extra conversion from a private field every time. I would like to know how we can eliminate those where it's a bottleneck.
• mwu: Reference is immutable; I'm hoping that LLVM's alias analysis will figure out how to get the address of the heap-allocated object once and so avoid paying the penalties more than once.
• mwu: Everything does have to be magic DOM, but you can have ones that have a single slot that points at the reflector.

till: What are the GC implications?

• People are worried. Need finalization off main thread - so should be using background object types. Otherwise you visit every object in the heap in the foreground object twice.
• mwu: If we don't need finalization, we can kill the finalizer. Most DOM node objects can have it eliminated. There are a few, like some input fields.
• Might be able to teach classes about how to free specific offsets from the JS engine (via the host's allocator)
• nmatsakis: If the object is Send, we may be able to run the finalizer from a background thread, since Send implies that is safe
• Working on taking marking off main thread, so only finalization would be on the main thread
• mwu: Also want to eliminate pointers w/in nodes. They store a tree structure; you should be able to store it elsewhere more efficiently. e.g., indexes w/ a table. Store it as a JS array, expose to JS...
• ajeffrey: If you have to compress it, don't you have to now write a GC in JS?
• bz: I just wouldn't gate your work on that, because there will be some compexities.
• mwu: I want to remove lots of the pointers inside of nodes.
• ajeffrey: Does this setup mean we don't have to trace Rust objects?
• mwu: Yes, in the vast majority of cases.
• ajeffrey: Is it 100%?
• bz: Could have event listeners, so you can't get out of it. Putting things into the array is hard.
• till: Could multi-heap help? Have things that are part of the DOM tree in their own heap.
• Sounds like you're not using zones, since everything in a different security context is already in a different thread and runtime. Could get rid of teh compartmental GCs, since you just want to clean everything. Don't know that it makes much sense to have a separate heap there. Something else is moving back to pinned values & allocating doubles on the heap again... would help with 32-bit size problems.
• bz: Should talk with Oleg about which things that the cycle collector collects well that now the GC will have to handle. THen, figure out how many of those are in real web pages, and you'll get a sense for how much more work you're putting on the GC. Certainly, the HTML spec with a half million DOM nodes is one such case. Possibly andrew (mccr8) too.
• If there are any GC problems, they're things that we need to fix for Gecko because they're related to our lists, too. Just bigger in Servo.

bz: You have something set up for rooting/tracing now, right?

• mwu: I think it works.
• bz: Hard case is creating an image, sets a load listener, and now the network fetch needs to keep the DOM node alive.
• jdm: We use persistent rooting for that.

larsberg: Have we answered questions about whether we actually want to do magic DOM or not?

• ms2ger: I'm worried about making heap allocations every time we touch a string, etc. from Rust... is touching strings from JS instead that much more important?
• mwu: We have to fix it anyway for reading strings.
• bz: How much of a problem is this string conversion problem? Or are you just running up against fundamental lower bounds?
• till: Much slower than gecko (in dromaeo) for things that touch strings.
• bz: Figure out what you're doing different from Gecko...
• ajeffrey: UCS2 vs. UTF8
• bz: You need to think long and hard about that.

bz: style system, when are tags interned and where?

• pcwalton: They're in the Rust string cache
• bz: Have a DOM object. Is that the same as the magic DOM object here? The one selector matching runs against?
• pcwalton: Yes. They are fields on an object.
• bz: What about new world?
• mwu: We have both a Rust atom string cache and the JS one...
• bz: If it's a JS string in the DOM object...
• mwu: It's not. All still native. Lots of optimization possible if we move to JS atoms instead of our own.
• pcwalton: Yes. Would hate to atomize during selector matching.
• till: Might be able to reduce copying by communicating the string representation between SM and Rust to avoid a conversion to export...

larsberg: So, how do we feel ?

• jdm: I like the transpiled language!
• ms2ger: I don't :-) So many new languages. JS, Rust, not-Rust/self-hosted...
• mwu: This will definitely give us the absolutely fastest bindings.
• ms2ger: It's also nice having compiled binaries. Now we have to delay startup times until JIT completes.
• till: Instead of JS source code could store the JS bytecode. Could certainly do for self-hosted SM code and should regardless of this conversation. After about 10 iterations, everything is super-fast.

bz: Is it possible to set this up to compile either to magic DOM or today-code?

• mwu: For struct side, yes. Provides some benefits to both today and tomorrow. Object layout can be switched. Not sure about the implementations.
• nmatsakis: I think it will work! We can look at the examples together.

Next steps

• Test this on a worst-case (tree traversal, lots of Rust code touching DOM objects, etc.).
• Contact Nikola for how to turn on alias analysis for references to reserved slots in DOM objects.