On 07/25/2013 01:36 PM, Boris Zbarsky wrote:
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?
This is a good idea. The only thing that's computed based on this right
now is tagName, but all of the downcasting implementation relies on
type_id as well.
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?
As I was starting to explain why non-roots wouldn't work precisely the
same, I realized I was incorrect.
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?
I don't see any difficulties arising from this setup with regards to
implementing or modifying. Trace hooks are manual like CC goop right
now, but there are plans to alleviate that. There are sanity check
assertions to ensure that all DOM objects fit within the available
space, so when you break the invariant you know the next time you run
Servo. The rest of the DOM code is unchanged from what it was, you just
pass around JSManaged<Foo> instead of @mut Foo now.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
