Workweek COW DOM

COW DOM

• gw: I'm aware of previous work, would like to know what went wrong.
• jack: wasn't so much that it was bad, we just got rid of it as we modified servo for parallel layout. there's a DOM node, a LayoutNode, and a ThreadsafeLayoutNode. idea that dirty pointers would be in scriptdata private field of Node (*() type) in script_task and actual node, could access the real type (dirty prev sibling, etc.) On layout side, there's a layout-only type that only sees the layout-relevant fields. There used to be phantom types that provided access, now we just use transmute for the PrivateLayoutData stuff.
• gw: where was the copy-on-write stuff?
• jack: it never existed. we used to run both tasks but it was obviously racy. old idea was script would trigger layout, and would only update dirty pointers, then once layout finishes it would copy dirty pointers to clean pointers.
• gw: patrick and I had a similar conceptual model, but maybe conceptually two separate versions of the DOM, one with JS roots, one with a compressed representation that is updated by script each time it's passed off to layout. the compressed stuff was very slow, several hundred ms for the html5 spec. bad worst case behaviour, lots of malloc...
• zwarich: still worry about ??? each frame while accessing normal DOM
• gw: (something about compressed representation being much better for cache performance since it's a flat array)
• zwarich: worry about constant factors of creating new data structure when you update the DOM
• pcwalton: we should not hedge Servo on COW DOM in general in my opinion. parallel layout is a big benefit; COW DOM is icing on the cake.
• gw: are the other things we can do?
• pcwalton: after style recalc, layout does not need to access the DOM.
• jack: so we could make join_layout return early, unless it's a query like getBoundingClientRect. we can terminate early unless responding to sync layout call.
• simonsapin: does style recalc include flow construction?
• pcwalton: yes, but wonder if style recalc could hang stuff off of separate data structure instead of DOM for flow construction - different overhead, but doesn't need to interact with the DOM.
• gw: if we can get to a point in the layout thread where we don't need the DOM any more, that would be good.
• pcwalton: selector matching is the most expensive part, but also very parallelizable, but we also have many optimizations we can implement (JIT, bloom filter, etc). we have ability to do much more parallel stuff than other browsers. worried about the complexity of COW DOM, but not sure that other parts aren't more important. it only really helps the case where script wants to receive events while style recalc is running, which is not necessarily common.
• zwarich: and when script sets something but doesn't query for it, since that's still sync
• pcwalton: if we can offer things like getComputedStyleAsync, that could be a bigger win for authors using them.
• jack: that doesn't help us now.
• pcwalton: we could do stuff like offsetTop async; keep running script until you need it? [ed. confusing; not sure what this was about]
• jack: let's turn on returning from layout after style ???, we should be able to do that today modulo bugs. then we can try to push it back to after style recalc...
• pcwalton: I like that.
• jack: more interesting to work on compressed DOM representation
• pcwalton: as designed with old COW DOM, could be quite hard to do compressed representation
• jack: other thing is what's the status of jdm's inline JS object representation?
• jdm: in a branch
• jack: for context, gecko engineers say that the performance of allocating reflector and DOM object is bad
• pcwalton: this is what IE9 is doing.
• jack: we should perhaps prioritize doing fused DOM objects and the compressed representation
• jdm: size of DOM objects is a problem
• zwarich: back when chrome was announced, v8 team was in favour of fused objects. would be good to find out if they've done research into the tradeoffs.
• pcwalton: looked into their oilpan slides. it's hard to apply their findings, since they have a stop-the-world conservative scan GC, which is much different than our situation since our DOM is single-threaded and no strong roots in layout.
• zwarich: they also haven't implemented it, but they also have two VMs they need to integrate.
• pcwalton: IE9 is most relevant but it's a black box. they seem happy with Chakra. in gecko we know that hybrid gc+rc is very difficult, and blink is similar. CC is still a performance and memory and safety problem.
• jack: could we have SM give us larger objects?
• jdm: maybe?
• jack: we can allocate numbers of fixed slots, so maybe we could have larger numbers available
• pcwalton: I think allocations are binned, but in theory any size should be possible
• zwarich: want to make sure that it doesn't harm regular uses of JS. reflector-free DOM seems more important than COW DOM.
• pcwalton: I do like the idea of building a compressed DOM as you recalc style, since that amortizes cache misses. you just do it as you go.
• zwarich: you're hoping that at style recalc time you have a bunch of changes batched together.
• jack: seems like a knob we could play with. do what current browsers do and batch as many as possible, or eagerly do some when we've seen some changes.
• zwarich: should probably prioritize some of the well-known problems like reflector-free DOM rather than ones that nobody has ever tried, are a lot of work, and have tradeoffs that are not entirely clear.
• abinader: patrick, what do you have in mind for selector matching?
• pcwalton: it's implemented, and embarrassingly parallel. the bloom filter is tricky, where you want to rule out ancestor selector. there's a qualcomm paper that solves it, using a solve filter you can copy between threads. we don't have that yet, may need string interning.
• zwarich: JITting will give a huge benefit.
• gw: do we have any concerns about JITting stuff and running on platforms that don't allow it?
• pcwalton: we should have a fallback
• jack: we can jit on android, right? only problem is iphone?
• pcwalton: yes
• gw: or on a console...
• pcwalton: you can disable the JIT(s) in spidermonkey
• zwarich: interpreter is quite slow, and can matter for real web content. I should write the CSS JIT sometime.
• pcwalton: I want to do it at parse time. Just generate code as you parse, no need for AST. Only thing we jit is the selector, and only thing the CSSOM can access is the text, so all you need to save is the text.
• zwarich: save a span into the original source... do we keep all decoded utf8 resources around?
• jdm: we definitely throw away html.