dynamically creating/deleting content and memory leaks

[Andrew Poulos]

If I code something like the following it results in a memory leak in IE
(as Leak 0.5 tells me):

var frm = document.create Element("FORM") ;
document.body.a ppendChild(frm) ;
fDeleteForm = function() {
document.body.r emoveChild(frm) ;
};

setTimeout( fDeleteForm, 100);
Is there a way to add and subsequently delete content without it causing
a memory leak in IE?

Andrew Poulos

[Eduardo Omine]

On Feb 8, 10:14 pm, Andrew Poulos <ap_p...@hotmai l.comwrote:

If I code something like the following it results in a memory leak in IE
(as Leak 0.5 tells me):

var frm = document.create Element("FORM") ;
document.body.a ppendChild(frm) ;

fDeleteForm = function() {
document.body.r emoveChild(frm) ;
};

setTimeout( fDeleteForm, 100);

You are calling a "global" variable (frm) inside fDeleteForm.
That's probably what's causing the memory leak.

[getburl]

On Feb 8, 4:14 pm, Andrew Poulos <ap_p...@hotmai l.comwrote:

If I code something like the following it results in a memory leak in IE
(as Leak 0.5 tells me):

var frm = document.create Element("FORM") ;
document.body.a ppendChild(frm) ;

fDeleteForm = function() {
document.body.r emoveChild(frm) ;

};

setTimeout( fDeleteForm, 100);

Is there a way to add and subsequently delete content without it causing
a memory leak in IE?

Andrew Poulos

Hi Andrew,

I have been recently trying to understand these memory leaks and I
think I understand yours. Please, if anyone sees fault in my
explanation, tell me so that we might all be further educated.

You have a variable referencing a DOM node. In IE, the DOM acts as
another variable. So, in your example, you have two references to the
same memory space: the form element you have created. Since, when you
remove it from the DOM you still have a reference to the created form
element via the variable frm, the Garbage Collector in IE does not
think this needs to be collected. If you wanted that memory space to
be released then set frm=null when you remove the element.

I suppose this is not a real memory leak since the data is not in an
orphaned space. It would be a leak if you had your example code in a
loop.

[VK]

On Feb 9, 7:54 pm, "getburl" <adampbr...@gma il.comwrote:

Please, if anyone sees fault in my
explanation, tell me so that we might all be further educated.

You have a variable referencing a DOM node. In IE, the DOM acts as
another variable.

No, but an element with ID attribute set will create global variable
with the same name as ID holding a reference to the said element. An
ugly IE's invention causing a bounch of hard-to-trace post-effects.
Alas adopted by many other UAs because of ugly written ASP pages
pollution on the Web. So they had to cope with the requirement "make
it compatible with..." It is not in direct relevance to the case
though.

So, in your example, you have two references to the
same memory space: the form element you have created.

No, just one reference JScript variable DOM element

Since, when you
remove it from the DOM you still have a reference to the created form
element via the variable frm, the Garbage Collector in IE does not
think this needs to be collected.

It does think that it should be collected, but it's directly
prohibited to do it. This kind of memory leak on IE is really special
because it's not caused by some engine failure - but directly
programmed by request to improve stability..
See
<http://groups.google.com/group/comp....avascript/msg/
1acf81f7d24d2ba 0>
for details.
In summary this leak is half-due to bad JavaScript programmers. If
they would follow specs and common sense and wouldn't create orphan
scripts - then Microsoft wouldn't have to fight with crashes caused by
scripting phantom DOM Tree out of orphan scripts.

>From the other hand if Microsoft would think in advance about Web

Application, kiosk mode etc. then they maybe choose some more elegant
fix than that.

If you wanted that memory space to
be released then set frm=null when you remove the element.

Amen!

[getburl]

On Feb 9, 9:20 am, "VK" <schools_r...@y ahoo.comwrote:

On Feb 9, 7:54 pm, "getburl" <adampbr...@gma il.comwrote:

Please, if anyone sees fault in my
explanation, tell me so that we might all be further educated.

You have a variable referencing a DOM node. In IE, the DOM acts as
another variable.

No, but an element with ID attribute set will create global variable
with the same name as ID holding a reference to the said element. An
ugly IE's invention causing a bounch of hard-to-trace post-effects.
Alas adopted by many other UAs because of ugly written ASP pages
pollution on the Web. So they had to cope with the requirement "make
it compatible with..." It is not in direct relevance to the case
though.

So, in your example, you have two references to the
same memory space: the form element you have created.

No, just one reference JScript variable DOM element

Since, when you
remove it from the DOM you still have a reference to the created form
element via the variable frm, the Garbage Collector in IE does not
think this needs to be collected.

It does think that it should be collected, but it's directly
prohibited to do it. This kind of memory leak on IE is really special
because it's not caused by some engine failure - but directly
programmed by request to improve stability..
See
<http://groups.google.com/group/comp....avascript/msg/
1acf81f7d24d2ba 0>
for details.
In summary this leak is half-due to bad JavaScript programmers. If
they would follow specs and common sense and wouldn't create orphan
scripts - then Microsoft wouldn't have to fight with crashes caused by
scripting phantom DOM Tree out of orphan scripts.>From the other hand if Microsoft would think in advance about Web

Application, kiosk mode etc. then they maybe choose some more elegant
fix than that.

If you wanted that memory space to
be released then set frm=null when you remove the element.

Amen!

VK,

Thank you for taking the time to correct the parts of my explanation
that were incorrect. It seems you left out enough to make me follow
your links and search on the terms you used. The MSDN article was very
interesting. If not for the value of the IE specific closure issues,
it illustrated the type of thinking that leads to buggy software
development.

getburl

[VK]

On Feb 9, 9:44 pm, "getburl" <adampbr...@gma il.comwrote:

Thank you for taking the time to correct the parts of my explanation
that were incorrect.

You are welcome.
What just came to my mind: the relevant "fix" was made approx 2003,
with IE 6 SP1 mass distribution. Undocumented CollectGarbage( ) method
in JScript is traced down to the same time IMO. Possibly this method
was added exactly for that fix, so "informed corporate customers"
could break the new leak.

That would be interesting to see if
CollectGarbage( );
instead of
frm = null;
breaks this kind of leak.

[RobG]

On Feb 9, 10:14 am, Andrew Poulos <ap_p...@hotmai l.comwrote:

If I code something like the following it results in a memory leak in IE
(as Leak 0.5 tells me):

var frm = document.create Element("FORM") ;
document.body.a ppendChild(frm) ;

fDeleteForm = function() {
document.body.r emoveChild(frm) ;

};

setTimeout( fDeleteForm, 100);

Is there a way to add and subsequently delete content without it causing
a memory leak in IE?

I think this thread explains it (despite the apparently irrelevant
subject):

"menus in JS or CSS - pros? cons?"
<URL: http://groups.google.com.au/group/comp.lang.javascript/
browse_frm/thread/15db740598c92a/89e410566f8b6b9 8?lnk=gst&q=ric hard
+cornford+circu lar+reference&r num=1&hl=en#89e 410566f8b6b98 >

The issue isn't simply closures or adding/removing nodes. It's about
circular references involving DOM nodes, usually created by adding
event hanlders.

--
Rob