This is similarly motivated, and a similar approach to Oilpan in Chromium (<a href="http://www.chromium.org/blink/blink-gc" rel="nofollow">http://www.chromium.org/blink/blink-gc</a>).<p>But because Oilpan is written in C++, there is still some manual annotation of GC'd members that needs to be done.
Does this suggest that "Encodable" isn't the right name for this trait, if it's being used for something that has nothing to do with encoding?<p>Visitable?
The interaction between native code and JS on the DOM is certainly an area of complexity and plenty of chance for subtle bugs in a browser implementation - I wonder if the observation that native code can only manipulate the DOM in a limited fashion compared to JS could be used to simplify things.<p>For example, the initial DOM tree will be created (by native code) when loading the document, and it needs to be freed as a whole when another (or the same) page is loaded. On the other hand, JS can create/add/remove objects on it, but they must not be freed if some parts of the tree still reference them. This suggests to me that some sort of ownership scheme is appropriate, and in the case of Servo they've decided to make the GC own everything - which certainly makes a lot of things easy - but it might be interesting to think of whether being able to transfer object ownership between GC and something else would have any advantages, e.g. "all objects in the DOM tree of the document are owned by their parent, and objects not in the DOM tree because they've either been removed from it or newly created by JS are owned by the GC."