Memory Leaks (Circular Reference?) in Internet Explorer causing problems.
Fox
action, when the engine has time to "look through" all the objects, determine which
ones will no longer be used for the rest of the program, dispose of them, and
release their memory.
thats a pretty tall order when you have a thread set to execute every 10 milliseconds...
garbage collection is automatic...it's not instantaneous...and there's a good chance
that if the program isn't screaming for memory, that it's not going to happen until
the page is unloaded.
if you want to "force" garbage collection (the "work-around") - you need to write
"clean" code -- set all references that need garbage collection to null [or manually
use 'dispose' on the object (not sure if IE supports it, check the docs)]. the
sooner the engine can determine the reference will never be used again [as in the
case of setting it to null] the sooner the object's memory will be reclaimed. even
at that, there is no guarantee the memory will garbage collected in a timely
fashion...only that it *will* be collected eventually.
i would say that a memory leak would be indicated if, after running your test, you
closed that page and the memory use remained...that would be a memory leak. if,
after you close the page, the memory used returns to normal, then there is no memory leak.
Fox
**************
whiskers_ wrote:
>
> I have created the following script which seems to highlight a memory leak
> in IE. I'm not sure why I am seeing this behavior as I thought that IEs
> garbage collection handled circular references gracefully.
>
> After about 200 to 300 iterations you will see a marked increase in the
> amount of memory being used by the IEXPLORE process in Task Manager.
>
> I did a couple of test pages to try and find a leak that I am getting in the
> project I am working on and this seems to be the only way I could get IE to
> leak relatively large amounts of memory. It appears to be related to the
> fact that I am using setAttribute() to assign my object to an attribute of
> the element whilst passing the element into the objects constructor and
> holding onto a reference internally within the object. The call to
> removeChild() does not seem to properly release the object as I would expect
> it to.
>
> Does any one know if this is a bug in IE? I guess I can work around it if
> that is the case but it is pretty annoying (in the large application I am
> working on we lose 2 to 3 MB of memory regularly from some of our more
> complex DHTML manipulation).
>
> Cheers,
>
> Jonathan Williamson
>
> --
> Senior Programmer
> Knowledge Support Systems
> willi...@kssg.com
>
> ------------- BEGIN HTML --------------
>
> <html>
> <head>
> <script language="javascript">
> function Object1( element )
> {
> var spaceWaste = new Array( 5000 );
> for( var i = 0; i < 5000; i++ )
> spaceWaste[ i ] =
> "012345678901234567890123456789012345678901234567890123456789012345678901234
> 5678901234567890123456789012345678901234567890123456789012345678901234567890
> 123456789012345678901234567890";
>
> this.element = element;
> }
>
> var element = null;
> function Loaded()
> {
> element = document.createElement( "div" );
> setTimeout( "WasteSomeSpace()", 10 );
> }
>
> var count = 0;
> function WasteSomeSpace()
> {
> if( document.body.firstChild )
> document.body.removeChild( document.body.firstChild );
>
> var obj1 = new Object1( element );
>
> element.setAttribute( "obj1", obj1 );
> element.innerText = count;
>
> document.body.appendChild( element );
>
> count++;
>
> element = document.createElement( "div" );
>
> setTimeout( "WasteSomeSpace()", 10 );
> }
> </script>
> </head>
>
> <body onload="Loaded()">
> </body>
> </html>
>
> ------------- END HTML --------------
whiskers_
I would agree, but the situation only occurs when using the code example
there, if you remove the circular reference or modify it so that the
circular reference is between two custom javascript objects not using
dynamic properties then the "memory leak" is not apparent.
While normally I would agree that a memory leak is only memory remaining
after a process has been destroyed if an application (or script host) causes
memory to be continually eaten until the system becomes unstable I would
consider this just as important as a memory leak..
I mean, if Windows ate memory constantly (but released it on shutdown) would
you be happy about it? ;)
Cheers,
Jon.
"Fox" <maho...@directvinternet.com> wrote in message
news:3CE93EEF...@directvinternet.com...
Fox
whiskers_ wrote:
>
> Fox, (if that is your real name! ;>)
Francis X. -- Fox fits (my father was "FX", so...) -- it's just a handle
>
> I would agree, but the situation only occurs when using the code example
> there, if you remove the circular reference or modify it so that the
> circular reference is between two custom javascript objects not using
> dynamic properties then the "memory leak" is not apparent.
do you get the same problem if you change the delay on settimeout to around 100 or
more? 10 is awfully intensive for an interpreted scripting language.
>
> While normally I would agree that a memory leak is only memory remaining
> after a process has been destroyed if an application (or script host) causes
> memory to be continually eaten until the system becomes unstable I would
> consider this just as important as a memory leak..
that depends -- usually an application has a certain amount of memory allocated for
it to run in -- how much "overhead" these objects use is a factor -- but if you have
say, 2MB of available memory and the objects use less than 1K per (they use a lot
more, i know) ...the application could generate 2000 objects before it would be
absolutely necessary to garbage collect them.
a memory "leak" implies that the application will saturate available memory, then,
eventually try to overrun it [page fault? on windows -- macs are different]. the
behavior i've usually noticed is when the javascript program starts to saturate
available memory -- the execution will start becoming erratic as the unused memory
is being cleaned up...if overrun, it will usually just stop (freeze) and the
application becomes completely unresponsive -- if you're lucky, you can
control-alt-delete [command-option-esc on macs] out of it. however, in many (most?)
cases, the browsers will do the best job they can to clean up the mess and carry on
-- it will just "look ugly" every so often as the running program "snags".
>
> I mean, if Windows ate memory constantly (but released it on shutdown) would
> you be happy about it? ;)
Yes -- then everyone would buy macs:D
I've looked over your original code again -- and yes -- you use removeChild [which
*should* (IMO) immediately release the memory -- but, as seen, often does not
immediately do so].
however, you are using something I never like to see:
setTimeout("whatever()",delay);
you are not assigning this to a reference -- therefore, it is being assigned to a
blind reference. If your code executes another one before the last one has a chance
to finish its task [as is often the case with a delay value < ~60 depending on
processor speed], the first will be overwritten and the memory gets "lost" for a
time (in some browsers, the command will execute anyway -- in others, the command
just "disappears" -- and in some -- the memory is never reclaimed because it becomes
"lost"). your code should check that the timer had in fact finished executing before
executing the next setTimeout OR, you should set up the timers in an array that
constantly grows to accommodate the references being generated and making sure the
thread is "cleared" before the page exits (e.g.: for (var i = 0; i < timers.length;
i++) if(timer[i]) clearTimeout(timer[i]); ).
setTimeout is not part of the core JavaScript/JScript/ECMAScript language -- it is a
browser dependant implementation -- a "service" for threading an application that
browser publishers provide (and there *are* differences). it needs to be handled
with care. since javascript was originally based (somewhat) on Java, some
investigation into Java threads and how they are handled, and some of the problems
that can arise if improperly handled, might be useful...at least educational.
you are right to suspect memory leaks -- all i've been implying is that without
actually crashing the application and/or your machine, you cannot be so quick to
judge that that is the case. I more quickly suspect your use of setTimeout as the
culprit than your other code in this example. i think you are expecting much more
from ie (or any browser!) than it can deliver in 10 milliseconds...and you are
asking quite a lot. consider the amount of memory that must be "managed". the data
for a DOM element alone, is HUGE. javascript is only an interpreted scripting
language, it takes, relatively [to a compiled language], to handle tasks like this.
slow this down by a factor of 10 [delay = 100 or greater] and see if you are still
getting the same results (you might not even notice the difference in "apparent"
execution speed). try applying the setTimeout reference to a variable and manage
that in a way that it's not being overwritten. there doesn't appear to be any other
reason why your code shouldn't function properly.
Fox
****************
Jonathan Williamson
> > I would agree, but the situation only occurs when using the code example
> > there, if you remove the circular reference or modify it so that the
> > circular reference is between two custom javascript objects not using
> > dynamic properties then the "memory leak" is not apparent.
>do you get the same problem if you change the delay on settimeout to around
100 or
>more? 10 is awfully intensive for an interpreted scripting language.
the problem occurs regardless of the timeout, i just set it high so that
impatient people would see the effects quickly ;)
> > While normally I would agree that a memory leak is only memory remaining
> > after a process has been destroyed if an application (or script host)
causes
> > memory to be continually eaten until the system becomes unstable I would
> > consider this just as important as a memory leak..
>
>that depends -- usually an application has a certain amount of memory
allocated for
>it to run in -- how much "overhead" these objects use is a factor -- but if
you have
>say, 2MB of available memory and the objects use less than 1K per (they use
a lot
>more, i know) ...the application could generate 2000 objects before it
would be
>absolutely necessary to garbage collect them.
This problem will cause IE to eat all memory available until the system
becomes unstable and "Out of virtual memory" errors plague your existence!
;)
> > I mean, if Windows ate memory constantly (but released it on shutdown)
would
> > you be happy about it? ;)
>
>Yes -- then everyone would buy macs:D
>
>I've looked over your original code again -- and yes -- you use removeChild
[which
>*should* (IMO) immediately release the memory -- but, as seen, often does
not
>immediately do so].
that what i thought.. in fact an interesting point is that using
removeChild() actually leaks *more* memory than doing
document.body.innerHTML = "";!! both leak memory, but the former is worse!
The way I implemented my timeouts is that the next timeout is triggered by
the completion of the execution of the code assigned to the previous
timeout.. so in theory they cannot end up "stacked".
setTimeout( "moo()", 10 );
function moo()
{
// do something time consuming here
setTimeout( "moo()", 10 );
}
should not cause timeout calls to stack because the next timeout is only
triggered once the code in the timeout function has completed executing. ie
the actual time between timeout calls would be ( function execution time +
timeout value ). Now admittedly that may not be the case if calls within the
timeout function are asynchronous, but I don't think that anything I was
doing in there was!
>you are right to suspect memory leaks -- all i've been implying is that
without
>actually crashing the application and/or your machine, you cannot be so
quick to
>judge that that is the case. I more quickly suspect your use of setTimeout
as the
>culprit than your other code in this example. i think you are expecting
much more
>from ie (or any browser!) than it can deliver in 10 milliseconds...and you
are
>asking quite a lot. consider the amount of memory that must be "managed".
the data
>for a DOM element alone, is HUGE. javascript is only an interpreted
scripting
>language, it takes, relatively [to a compiled language], to handle tasks
like this.
I fully appreciate the complexity of the DHTML DOM, i've been working with
it for years and I bow down to the guys at Microsoft for their
implementation wholeheartedly! I think for quality of application Internet
Explorer is my #1! But that said, every program has it's glitches (and for
it's size and relative complexity IE has very few)...
Cheers,
Jon :)
Jim Ley
<jwhis...@hotmail.com> wrote:
>that what i thought.. in fact an interesting point is that using
>removeChild() actually leaks *more* memory than doing
>document.body.innerHTML = "";!! both leak memory, but the former is worse!
removeChild does return the node remember, you're just throwing it
away, does more explicit killing of the reference
x=...removeChild()
x=null
help any?
IE's garbage collector is very wary of running, Peter Torr (IIRC)
posted details of it which you can find in groups google.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jonathan Williamson
I suspect it is not the node that is failing to get destroyed correctly,
rather my custom javascript object, which is circular referenced by the
dynamic property set on the node..
I did read about the garbage collection but the indication from that was
that it cleared up much more regularly than this example displays.
Cheers,
Jon.
"Jim Ley" <j...@jibbering.com> wrote in message
news:3cea111e...@news.cis.dfn.de...
Jim Ley
"Jonathan Williamson" <jwhis...@hotmail.com> wrote in message
news:uxqMTqKACHA.2580@tkmsftngp05...
> That makes no difference to the example.
Not surprised...
> I suspect it is not the node that is failing to get destroyed
correctly,
> rather my custom javascript object, which is circular referenced by the
> dynamic property set on the node..
Sorry, I missed that you had a circular ref. That won't get GC'd
according to information given here, JScript's GC isn't that advanced -
Avoid circular refs!
Jim.
Jonathan Williamson
>
> "Jonathan Williamson" <jwhis...@hotmail.com> wrote in message
> news:uxqMTqKACHA.2580@tkmsftngp05...
> > That makes no difference to the example.
> Not surprised...
> > I suspect it is not the node that is failing to get destroyed
> correctly,
> > rather my custom javascript object, which is circular referenced by the
> > dynamic property set on the node..
>
> Sorry, I missed that you had a circular ref. That won't get GC'd
> according to information given here, JScript's GC isn't that advanced -
> Avoid circular refs!
But JScript *does* clear up circular references, I have written many test
harnesses to try and trap the memory problems we are having and circular
references appear to be dealt with prefectly.. for example.. (written off
the top of my head so forgive a mistake or two ;>)
function Obj1()
{
// put some large member variables here, an array of long strings for
example.
this.other = null;
}
function Obj2()
{
// put some large member variables here, an array of long strings for
example.
this.other = null;
}
setTimeout( "WasteSpace()", 10 );
function WasteSpace()
{
var obj1 = new Obj1;
var obj2 = new Obj2;
obj1.other = obj2;
obj2.other = obj1;
setTimeout( "WasteSpace()", 10 );
}
This will not cause memory to creep upwards during execution, IE clears out
the circularly referenced objects..
Odd isn't it? :)
Cheers,
Jon.
Hans Gommers
it?
"whiskers_" <jwhisker...@hotmail.com> schreef in bericht
news:fQ3G8.205$kk7....@news8-gui.server.ntli.net...
whiskers_
subject) and through some basic test pages that the JScript garbage
collector will handle circular references.
Ie, if the garbage collector notices that the only references held to an
object are by other objects which themselves have no references (other than
ones from other objects which have no references.. etc..!) then the
collector will destroy them anyway.
I can prove that this works with two standard Javascript objects.. but it
seems to fall apart when one of the circular references is held as a dynamic
property of an element..
Cheers,
Jon.
"Hans Gommers" <hans.g...@ksdnet.nl> wrote in message
news:uibNbkMACHA.1208@tkmsftngp02...
Fox
previous points taken...
>
> I fully appreciate the complexity of the DHTML DOM, i've been working with
> it for years and I bow down to the guys at Microsoft for their
> implementation wholeheartedly! I think for quality of application Internet
> Explorer is my #1! But that said, every program has it's glitches (and for
> it's size and relative complexity IE has very few)...
I don't share your enthusiam. I think IE has been completely overblown since the
its beginning and loaded with redundancy after redundancy. I don't believe the
programmers of IE really took any care in designing the scripting engine exposure to
the DOM as evidenced by the fact that there are at least three different sets of
values that indicate 'left' and 'top' [and i personally suspect that this craziness
was done on purpose to try and "undo" compatibility with navigator -- PLUS -- I'd
like to know the "genius" that came up with the idea of leaving OUT the absolute
position of every element on a page, once positioned, requiring "tracing" through
the hierarchy to get the absolute position -- since they're wasting so much memory
anyway, the could have sacrificed 2 more integers per element to give us that
information easily -- Netscape does]. It's appalling that NN6 has followed suit and
that the behemoth proportions that browsers are taking on is counter to the idea of
a pleasant browsing environment. To date, there hasn't been anything (worth doing
with a browser) that I haven't been able to accomplish in NN4 that everybody raves
about in IE5+ (and then some -- even overline underline hover effects -- and they
respond better in NN4). IE still does not behave with CSS as you would expect it to
[have run into many recent problems with disparaging differences in the way NN6 and
IE5 handle what should be w3c standards -- most distressing but not unreparable --
favor IE, repair in NN (it's easier that way)]. After 7 years (maybe it's 6 -- IE
was somewhat "late" on the scene), M$ has yet to win my affection (and i doubt it
ever will)...even the core JScript language is flawed [inability to handle the
simplest of computer operations properly: & (and others)]. It has been, and still
is, an "embarassment" (obviously IMO)...but, "everybody" uses it... so... If you
found a big gaping hole in it -- I'm glad -- I applaud you...but I'm not grinning
from ear to ear...or even slightly. It's just sad. The more "crap" they build into
browsers, the less reliable they become...the harder they are to program...
do take care with setTimeout though...some of us are still idiots...some of us still
browse with NN4...and you cannot depend on one implementation of setTimeout to
behave the same with other implementations (and these days, that goes beyond just IE
and NN).
Peace.
Out,
Fox
**************
whiskers_
Whoa Fox!
What an outpouring of grief ;)
Luckily I am not required to support NN in anyway shape or form ;)
I do agree with some of your points, and up until around version 5.5 IE was
a crawling behemoth.. I agree wholeheartedly with the idea of being able to
retrieve the absolute position of an element without "walking the tree"
(life could be so sweet :>).. But I'm not so livid with regard to the
redundancy of properties on elements. A lot of that redundancy is due to CSS
and the fact that a lot of CSS attributes mimicked properties IE had
previously gone ahead and implemented (and no, I know IE doesnt really keep
in step with the W3C but progress is progress right?) ;)
I think IE has finally started to mature (bar the daft stuff like plug in
browser bars, channels *ahem* and some of the other extraneous gumpf they
appear to tack on as an after thought ;>) I find I can do almost anything in
IE (with much less constraint than NN).. Our application requires an
interface that is comparibly "active" as any MFC/ATL/VB application can be
trees, lists, input validation and feedback, tabs, custom combo boxes, etc..
Given that we need to scale over intranet our only sensible choice (being as
though .Net was a little in the future back then) was to create an extremely
rich web based interface, which we found only IE was capable of truly
delivering :)
I'm not interested in the pro MS/anti MS argument, it's a long and tortuous
path to follow ;)
Your comments have been useful with regard to my problem, I shall struggle
on! ;)
Cheers,
Jon.