On 7/25/13 9:25 AM, Josh Matthews wrote:
type_id is an enum to distinguish between node types, with an inner enum in the element case to distinguish the kind of element. All enums are automatically 8 bytes, and if any variant contains another enum that automatically bumps it up to 16.
OK. So I think we should consider doing something like what Gecko (and iirc WebKit) does: nodes have a pointer to a "nodeinfo" struct which stores all the information that is invariant across all nodes of a given type with a given ownerDocument. This would store the localName, namespace, owner document, nodeName, etc, etc.
One issue is that adopting can change some of this stuff, so we'd need to use a COW setup for this pointer, presumably...
I guess what happens right now is that things like localName are computed from the nodetype/elementtype enum values?
The wrapper field is a *JSObject essentially, which I suppose could conceivably go away if we dictated that the wrapper pointer could be determined by finding the memory position at self - (sizeof(JSObject) - sizeof(JSVal) * MAX_FIXED_SLOTS) when self is the root of a DOM hierarchy.
Right. Why would this be limited to roots? What's the self pointer for non-roots?
The nagging question I have, I think, is how easy is it to implement a new DOM object in this setup? One reason we're trying to avoid the CC/tracing boilerplate is that it's annoying/confusing to write and error-prone so people new to implementing DOM objects often screw it up, right? What are the constraints on DOM object implementers in the new setup, and how are they enforced? How do they affect the experience of implementing, or modifying the implementation of, a DOM object?
-Boris _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
