[webkit-dev] DOM tree traversal on detached nodes

[Kentaro Hara]

Thanks Maciej

I am trying to implement a WIP patch that guarantees "Reachable DOM nodes
are kept alive", without regressing performance nor without adding member
variables to Node objects. The patch will remove guardRef() as a natural
consequence. Although I'm not 100% sure if the work succeeds or not in
terms of performance, I'll upload the patch and a document in a week or so.



On Tue, Jun 12, 2012 at 10:06 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jun 6, 2012, at 6:27 PM, Darin Adler <darin at apple.com> wrote:
>
> On Jun 6, 2012, at 6:14 PM, Kentaro Hara <haraken at chromium.org> wrote:
>
> IMHO, (a) would be the best semantics.
>
>
> I agree, and I think that the specification actually does require this.
>
> The real issue here is how to fix this bug efficiently. I believe that
> Geoff Garen has been contemplating this and also has a proposal for how to
> do it.
>
>
> I vaguely recall that I originally implemented rule (b) for WebKit, and at
> the time I did it because:
>
> (1) The exact behavior in this case seemed unimportant; I couldn't find
> any sites depending on it, nor did it seem likely that they would.
> (2) It was the simplest apparent way to avoid leaking certain kinds of
> cycles that span GC and refcounting (I don't remember the details and this
> is likely no longer applicable)/
> (3) It seemed that keeping ancestors alive would have the potential to
> hold large amounts of memory when much of it was unneeded.
>
> An even more extreme example of (3) would result if both parentNode and
> ownerDocument were strong references, and ownerDocument was made to be a
> real reference, not a self-only reference (at some point renamed to
> guardRef). Then keeping a single node that was in an isolated DOM subtree
> alive would also keep that whole document alive. I am not sure what other
> browsers do in this case.
>
> Of course, predictability might outweigh the potential memory use issues.
>
> Regards,
> Maciej
>
>


-- 
Kentaro Hara, Tokyo, Japan (http://haraken.info)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120612/3c16b385/attachment.html>