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 <[email protected]> wrote: > > On Jun 6, 2012, at 6:27 PM, Darin Adler <[email protected]> wrote: > > On Jun 6, 2012, at 6:14 PM, Kentaro Hara <[email protected]> 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)
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
