Meeting 2013 09 09

Servo Meeting 2013-09-09

Agenda

• crashes
• incremental flow tree construction
• test harness / dromaeo / etc
• strings
• spidermonkey c api

Attending

azita, bz, jdm, jack, pcwalton, brson, kmc, lbergstrom, bholley

crashes

• kmc: two crashes left related to shutting down glfw before skia. we seem to be valgrind clean except for things relating to that. should be fixed soon

incremental flow tree construction

• pcwalton: https://github.com/mozilla/servo/wiki/Incremental-flow-tree-construction
• jack: how are frame trees constructed in gecko?
• bz: when nodes are added removed there are listeners that call Frameconstructor asynchronously. something changes, post an event, when it fires mark the subtree that needs a new frame. there are bits that say whether descendants need frames construtor or if the ndoe needs a frame constructed. you walk down the tree and constrcut what you need to do.
• pcwalton: do you reuse frame?
• bz: in gecko, there is a dom tree, a frame tree, and a layout tree. various style changes will dirty layout but not require reconstrcuting frames. the process is described covers the case where hte frame tree needs to change.
• pcwalton: if you add a dom node, it will flag the parent as needing frames updated?
• bz: when you add a dom node, it flags the node as 'this needs a frame' and the anscestors as 'some kid needs a frame'. frame construction is a two step process. you construct a representation of what you plan to create (frame construction items), then you figure out it's ok to create them in place or rejigger a bigger part of the frame tree. reusing them turned out to be really complicated so we switched to this thing.
• bz: the webkit approach is interesting. it makes some things harder (table anonymous boxes, etc) since you need non-local analysis.
• pcwalton: webkit approach isn't easily parallelizable, virtual methods allowed to do whatever they want
• bz: could be parallelizable, all frame constructor elements independent of each other
• bz: reason frame construction isn't bottom up in gecko is ... there's inherent top-down in operation (inheritance). in general if you have node with no interesting kids you know what kind of box you make. as you go up, you figure out what parents need to do
• pcwalton: interesting is what output of current function is. each dom node doesn't correspond to a flow, but it corresponds to a box (inlines collapsed to parent box), need place to hang temporary result of flow tree construction. if have nested inlines, may correspond to multiple temp flows that could be collapsed. not sure exactly how will work.
• bz: we try to construct as few frame construction items as possible in gecko. don't creat ethem for entire subtree, only for things that need them (ie. blocks inside inlines). worst case: body contains unclosed span. want to decide quickly whether to reconstruct span without creating frames for every child.
• pcwalton: decide if we need ib splits early, optimize that case in incremental construction.
• bz: consider "display on outside" versus "display of my kids" — e.g. inline-block is outside inline, kids are block

test harness / dromaeo

• jack: what benchmark tests should we be using?
• bz: dromaeo has js tests which you can ignore. it has css tests, which are tests of jquery performance. to some extent those are gated on js, but if we were significantly slower on those than equiv spidermonkey than perhaps it's worth looking at. it has dom tests which are micro-benchmarks for fast path through dom bindings, but not worth obsessing over. really focused on DOM side, not much layout interaction.
• pcwalton: is the maze solver worthwhile?
• bz: it has a whole bunch of divs that are positioned offscreen adn then onscreen by setting transforms. it sets a class and has some inline style. pcwalton: it sovle the maze using javascript?
• bz: yes. but the main performance cost is the divs. in gecko if you changed transforms it has to reframe and then relayout the parent, and then you have to relayout all 900 divs every time. and the repainting sucked. maze solver falls back to absolute positioning if transforms don't work.
• bz: peacekeeper is very hard to work with. there's a lot of js stuff in there. i wouldn't worry about for now.
• pcwalton: also seems pretty canvasy.
• jack: we've fixed the blockers for dom bindings performance (scheduler, ffi wrappers). should we revive the benchmarking work we were doing?
• pcwalton: yes.
• brson: there's one missing piece of the scheduler. spidermonkey can't steal right now.
• pcwalton: we can probably benchmark selector matching.
• jack: yeah, we'll ned a baseline to compare for simon's new stuff.
• brson: the feature that's missing is the aiblity to add workstealing schedulers at runtime.
• jack: was that high up on the list?
• brson: there's some stability bugs, so it wasn't high up on the list.

strings

• pcwalton: it would be nice to have dynamically sized enums: enum MyString { Ascii([u8]), Ucs2([u16]) }
• jack: we could use owned vectors for now until DST is available.
• pcwalton: you want ref counted strings and interned strings. in gecko you can treated an interned string as a ref string which is kind of nice.
• bz: the hierarchy has some benefits. the code will just accept any string. the drawback is that it's more complicated and the gecko hierarchy is arleady so complicated. perhaps if the hierarchy is simpler it would be worth it.
• pcwalton: how often do we need owned backing stores vs. ref counted backing stores vs. threadsafe backing stores.
• bz: there are two refcounts, a non-threadsafe ref count and a thread refcount. they have something optimized for the case where it never goes off thread.
• pcwalton: so it switches to a threadsafe i think jack: is it useful to optimize the single threaded behavior in servo?
• bz, pcwalton: probably not
• bholley: we could eagerly make jsstrings for anything comeing from the parser.
• pcwalton: if that's fast it might work
• bz: that might be a reasonable way to go.
• bz: it's not just tagName, it's attribute values, textContent.
• pcwalton: there is weird charset stuff though
• bz: jsstrings are always unsigned 16 bit sequences. the biggest problem for ucs-2 is that you encounter it only in extreme cases, but in utf8 you hit it as soon as you hit non-ascii. for the most part js does not treat strings as text but as arrays.
• pcwalton: if you just have ascii you can store it specially, but we'd have to add it to spidermonkey.
• pcwalton: if the stuff that comes from the parser are jsstrings then we have to copy them to hte frame tree.
• bz: spidermonkey has talked about adding a refcount for this.
• bz: i think we end up copying text into text runs in gecko.
• pcwalton: maybe that's not so bad. i wonder in what cases for thread safety.
• bz: stupid stuff like selector matching needs strings.
• bz: say you have a selector that matches on a value of an attr. what gecko does right now is asks the node what's the value and compares the two values. when you ask for the attr val it hands you a string. that would require threadsafe refcount, but there are other ways to do this. you have to be somewhat careful when you do stuff.
• simon: selector matching is the next thing i'm going to work on. should i do it without interning?
• pcwalton: you could intern predefined tag names. with an enum that it's a predefined tag name or a pointer to an owned string. qualcomm's strategy was to eagerly intern ids and classes in the html parser.
• kmc: do we have a html ast separate from the dom?
• pcwalton: just the dom. it's probably too much memory to have another one.
• bz: gecko interns at setAttr time. in the class case you get an array of interned values.
• pcwalton: well known attribute names are also candidates for interning.
• bz: there are some tradeoffs. if you look at getAttr microbenchmarks, if you don't have too many attributes it's cheaper not to intern a string. doing compares that fail fast is actually cheaper. i think gecko is perhaps more intern happy than it needs to be.
• pcwalton: simon, maybe the thing to do is to not intern stuff and just throw in stuff later until we're happy.

spidermonkey c api

• bz: where would the c api live?
• jdm: it would be in rust-mozjs
• pcwalton: maybe swig i the best appraoah.
• jdm: apparently there's not much supprot for C++ to C swig support.
• bholley: when we rev spidermonkey we can use zones, which is the gc unit. one advantage in gecko is that every tab is its own zone, then when you kill the tab it's easy to get rid of everything.
• bz: the interesting thing is the lag time between closing a tab and the memory being freed.

.... lots of discussion about how zones interact with cross domain and multiple tabs...