On 02/16/2013 08:50 PM, Patrick Walton wrote:
I have started work a new DOM implementation in the "dom" branch. It is
currently building except for an internal compiler error, the fix for which is
currently being upstreamed to Rust.
This new DOM implementation is based on structs instead of enums. The base type
is `AbstractNode`, which is an opaque pointer with many accessors that
let you query what type of node it is and downcast appropriately. (I'm thinking
of changing `AbstractNode` to `Node` and changing the concrete `Node`
to something else, though, because the word `Abstract` is littering the
codebase.) When structs are allowed to inherit from other structs in Rust,
then the implementation will become a bit simpler and will use less unsafe code
internally.
The advantages of the new implementation over the previous one are (a) several
layers of indirection are gone; (b) the copy-on-write interface is
dramatically simplified, eliminating the need for answers to annoying questions
like how to collect dead handles; (c) DOM nodes now only take up as
much memory as they need to; (d) we can make borrowing of nodes sound, because
the new interface is amenable to the dynamic checks described in Niko's
"Imagine Never Hearing the Phrase 'Aliasable, Mutable' Again" blog post.
This new DOM implementation currently exposes an unsafe interface in a few ways:
(1) When creating a node (converting from the base type to AbstractNode), there
is no check performed to ensure that the thing you passed in actually
is a Node, and moreover that it is the node that you claimed it was. This can
be fixed by providing safe wrappers around node constructors and moving
the low-level node constructors into the trusted computing base (hereafter
TCB). These constructor primitives are very simple operations, so the TCB
should remain easy to audit for security. It can also be fixed to some degree
by adding struct inheritance to Rust, as I plan to propose. But note
that node construction must remain part of the TCB to some degree, because
nodes are owned by the SpiderMonkey garbage collector and not the Rust
garbage collector.
(2) Borrowing of nodes (i.e. downcasting from AbstractNode to a concrete Node
subclass) currently does not perform the dynamic checks needed for
safety. What this means is that it is possible to cause segfaults with certain
combinations of mutations and pointer borrowing. The fix will simply be
to add these checks. Once these checks are added to the TCB, segfaults should
not be possible in the safe Servo code.
(3) There is nothing currently preventing Rust code in the script task from
accessing (and racing on) layout data structures, and layout from
accessing dirty nodes. I believe this can be fixed with phantom types: layout
will see a type that prevents access to the dirty parts of nodes, and
script will see a type that prevents direct access to layout info.
I believe there are solutions to each of these problems, and of course fixing
them is a high priority for the project. But note that, as I described
before, there will always be some unsafe code relating to node memory
management as part of the TCB, because SpiderMonkey's garbage collector manages
the nodes. The goals are (a) to use as little unsafe code as possible, and,
most importantly, (b) to prevent the unsafeness from leaking out into
script and layout code.
Curious, how does GC manage nodes? Do we explicitly trace even those nodes
which don't have js wrappers or do
we just use GC for everything in Rust?
How do we keep GC times fast enough? Will generational GC optimize out those
nodes which aren't used lately?
(Doing explicit optimizations is easier when using CC. That is how Gecko
manages to keep pretty much all the
DOM nodes out from CC graph when there are no nodes to collect. But of course
the clean up phase takes some short amount time.)
-Olli
Finally, note that the copy-on-write scheme is not yet implemented; right now
script will just block on layout. Fixing this is a high priority as well.
Patrick
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
