- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 26 Aug 2010 23:03:17 -0400
On 8/26/10 10:33 PM, James May wrote: > Could the iframe be hoisted to the top level of its parent browsing context? Not sure what you mean. > When no references remain in either the DOM or script? > > if an |iframe > <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>| > is removed > <http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#remove-an-element-from-a-document> > from a |Document > <http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>| > and is then subsequently garbage collected It can't become garbage collected while the window inside it isn't, since the window inside it references the iframe (via frameElement). > this will likely mean > (in the absence of other references) that the child browsing context > <http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#child-browsing-context>'s > |WindowProxy > <http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#windowproxy>| > object will become eligble for garbage collection I don't think it's reasonable to gc the <iframe> element while leaving the window inside alive due to it being referenced. That introduces races where frameElement could suddenly become null at some point (possibly between two lines of the same script, or even partway through some operation; for example GC can happen, even multiple times, during a property get or set). That would be pretty broken behavior. > Although I'm not sure why this is different from the regular steps. Presumably the only different thing is the lack of an unload event. > Can they, with your proposal? It seems that with your proposal if > you remove an iframe from the DOM and then forget about it then as > long as there's any network activity in that iframe or anything else > which might potentially trigger script it cannot be gced. This > seems like it would make it very easy to leak document after document... > > So running scripts and network activity are GC roots? Not running scripts. Anything that might potentially run a script in the future. You can think of it as gc roots, sure, and you can also claim that gc'ed systems never leak memory. But is either necessarily useful? The upshot is that random things that the web developer knows nothing about and doesn't care about can prevent the memory from being deallocated effectively forever from the web developer's point of view. And worse yet, there's no obvious recourse (as in, no way to make sure the thing is garbage collected). Any reasonable person would call that a memory leak in the browser, not in the site. Just like a JS impl that never GCes until you navigate away from the page should be considered to have a memory leak. -Boris
Received on Thursday, 26 August 2010 20:03:17 UTC