- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 21 Aug 2012 09:40:23 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Ryosuke Niwa <rniwa@webkit.org>, Ehsan Akhgari <ehsan@mozilla.com>, Sukolsak Sakshuwong <sukolsak@google.com>, Kentaro Hara <haraken@chromium.org>, Maciej Stachowiak <mjs@apple.com>, Olli Pettay <Olli.Pettay@helsinki.fi>, public-webapps <public-webapps@w3.org>, Ojan Vafai <ojan@chromium.org>
[Re-sending from the proper address.] On Tue, Aug 21, 2012 at 1:54 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Mon, Aug 20, 2012 at 11:56 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: >> No. Allowing the host to be moved without removing automatic transaction is >> what causes the problem because automatic transactions need to keep relevant >> nodes alive. >> >> Essentially, this has the same problem has the magic iframe. We can >> alternatively change the way automatic transactions work so that they don't >> retain the original nodes but that model has its own problems. > > I'm not entirely sure what "the magic iframe" is. But this simply > seems like a shortcoming in the WebKit memory model. Dealing with > cycles in C++ objects is a solved problem in Gecko and I'm surprised > if this doesn't happen in other situations in WebKit too. WebKit is not able to handle cycles in C++ objects without leaking memory. There's no equivalent to Gecko's cycle collector. > How do you for example deal with the fact that if you create two > nodes, A and B, and make A a child of B. As long as a reference is > held to either A or B you need to keep both nodes alive. But as soon > as the only thing holding references to A and B are just A and B, both > nodes need to be GCed. Managing the lifetime of Nodes efficiently is quite complicated. As a simplification, you can imagine that we keep track of external references to the tree separately from internal references within the tree. Adam
Received on Tuesday, 21 August 2012 16:42:02 UTC