- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 21 Aug 2012 01:54:47 -0700
- To: Ryosuke Niwa <rniwa@webkit.org>
- Cc: Ehsan Akhgari <ehsan@mozilla.com>, Sukolsak Sakshuwong <sukolsak@google.com>, Kentaro Hara <haraken@chromium.org>, Maciej Stachowiak <mjs@apple.com>, Adam Barth <abarth@webkit.org>, Olli Pettay <Olli.Pettay@helsinki.fi>, public-webapps <public-webapps@w3.org>, Ojan Vafai <ojan@chromium.org>
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. 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. / Jonas
Received on Tuesday, 21 August 2012 08:55:44 UTC