6 ms·

In every browser except IE4-7, removing the DOM node from the document would result in the entire lot getting garbage collected. This is garbage collection coll

In every browser except IE4-7, removing the DOM node from the document would result in the entire lot getting garbage collected. This is garbage collection collecting garbage. However, in IE4-7 the JS garbage collector isn't responsible for handling DOM nodes and vice versa. Consequently, this results in a memory leak; in IE 4-6 this persists until the browser terminates, and in IE7 it persists until the user navigates to another page. There is a related application-level memory leak if you have some other reference to the closure that doesn't belong to the DOM node, and that applies to all browsers. See http://news.ycombinator.com/item?id=2567847 http://news.ycombinator.com/item?id=2567847 for a simple way to deal with that.

pbiggar 15y ago
The OP never mentions removing the node from the DOM.
- DrJokepu 15y ago
  It's kind of implied, isn't it? I mean, it wouldn't make sense to expect something that's still part of the DOM tree to get garbage collected, would it? Unless I'm missing something?
  - pbiggar 15y ago
    You're right. My initial reading was the closure closed over extra objects (which would be a leak so long as the DOM node is live), but I think the OP is worried about the DOM node leaking.
- spjwebster 15y ago
  It was an assumption I made in my reply (now corrected) but it doesn't matter; even without removing the node from the DOM there's a memory leak in IE4-6, one that persists until the browser is terminated. In the other cases, there's no memory leak while the DOM node still exists, because the DOM still has a reference to it so it shouldn't be garbage collected.
masklinn 15y ago
> However, in IE4-7 the JS garbage collector isn't responsible for handling DOM nodes and vice versa. It's a little sad that you don't expand on this, for those in the audience who do not know of this issue. So I will: In IE up to IE7, Javascript lives in the jscript engine (equivalent to one V8, Tamarin, Rhino or what have you), but DOM objects are actually COM objects. COM objects are handled with a COM runtime, and there is an interface through which jscript interacts with COM. MSIE4-7 has no issue with jscript circular references (it uses a mark & sweep GC, immune to the issue), and the COM engine ensures there are no issues with circular references in the DOM (COM uses refcounting but — as in Python for instance — has cycle detections). Issues, as usual, arise at the boundary: if a jscript object has a reference to a (COM) DOM node, or a DOM node has a reference to a jscript object, it creates a foreign reference which will not be cleaned up until the holder object on the other side of the interface is done with. For both garbage collectors, those foreign references are completely opaque, the only thing they know is that those exist but they have no way to know what happens on the other side of the jscript-COM interface. This means if there is a cycle crossing the boundary (twice), neither garbage collector is able to clean it up. And there is no Breach, able to take care of boundary issues such as this. And it leaks. A lot. In fact, it leaks so much that a few years ago a tool was tested with the sole purpose of reloading a page and carefully monitoring the objects which fail to be cleaned: drip.

pbiggar 15y ago

The OP never mentions removing the node from the DOM.

DrJokepu 15y ago
It's kind of implied, isn't it? I mean, it wouldn't make sense to expect something that's still part of the DOM tree to get garbage collected, would it? Unless I'm missing something?
- pbiggar 15y ago
  You're right. My initial reading was the closure closed over extra objects (which would be a leak so long as the DOM node is live), but I think the OP is worried about the DOM node leaking.
spjwebster 15y ago
It was an assumption I made in my reply (now corrected) but it doesn't matter; even without removing the node from the DOM there's a memory leak in IE4-6, one that persists until the browser is terminated. In the other cases, there's no memory leak while the DOM node still exists, because the DOM still has a reference to it so it shouldn't be garbage collected.

masklinn 15y ago

> However, in IE4-7 the JS garbage collector isn't responsible for handling DOM nodes and vice versa. It's a little sad that you don't expand on this, for those in the audience who do not know of this issue. So I will: In IE up to IE7, Javascript lives in the jscript engine (equivalent to one V8, Tamarin, Rhino or what have you), but DOM objects are actually COM objects. COM objects are handled with a COM runtime, and there is an interface through which jscript interacts with COM. MSIE4-7 has no issue with jscript circular references (it uses a mark & sweep GC, immune to the issue), and the COM engine ensures there are no issues with circular references in the DOM (COM uses refcounting but — as in Python for instance — has cycle detections). Issues, as usual, arise at the boundary: if a jscript object has a reference to a (COM) DOM node, or a DOM node has a reference to a jscript object, it creates a foreign reference which will not be cleaned up until the holder object on the other side of the interface is done with. For both garbage collectors, those foreign references are completely opaque, the only thing they know is that those exist but they have no way to know what happens on the other side of the jscript-COM interface. This means if there is a cycle crossing the boundary (twice), neither garbage collector is able to clean it up. And there is no Breach, able to take care of boundary issues such as this. And it leaks. A lot. In fact, it leaks so much that a few years ago a tool was tested with the sole purpose of reloading a page and carefully monitoring the objects which fail to be cleaned: drip.