By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,741 Members | 2,004 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,741 IT Pros & Developers. It's quick & easy.

Javascript memory leaks?

P: n/a
Jack Slocum claims here

http://www.jackslocum.com/yui/2006/1...id-javascript-
memory-leaks/

that "almost every site you visit that uses JavaScript is leaking memory".

Anybody know anything about this?
Does *Javascript* leak memeory, or
does the *browser* leak memory?
Oct 3 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Jim Land wrote:
http://www.jackslocum.com/yui/2006/1...id-javascript-
memory-leaks/
that "almost every site you visit that uses JavaScript is leaking
memory".
I'm skeptical. This conclusion would require that the "Leak Extension" for
firefox be detecting only valid leak scenarios. I see no proof or evidence
on its site that this is the case. Experienced javascript developers _know_
when leaks are created and can easily scan code for closures with circular
references in their scope chain, for example.

Since FF doesn't suffer from the same circular reference problem that IE
does, I'm not sure how this extension can reliably detect situations where
IE would leak memory.
Does *Javascript* leak memeory, or
does the *browser* leak memory?
Javascript as a language certainly cannot leak memory, because there is no
way to manually allocate and deallocate memory. Since it is garbage
collected, it's up to the host environment to worry about cleaning up
memory. So, it's the browser's implementation of javascript that would cause
a memory leak.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Oct 3 '06 #2

P: n/a
Matt Kruse wrote:
Jim Land wrote:
http://www.jackslocum.com/yui/2006/1...id-javascript-
memory-leaks/
that "almost every site you visit that uses JavaScript is leaking
memory".

I'm skeptical. This conclusion would require that the "Leak Extension" for
firefox be detecting only valid leak scenarios.
It reports memory leaks only for very specific cases (and seems
somewhat buggy at that). I don't know whether it tests for actual
leaks or just scenarios that might induce leaks. I tested adding a
closure using both dot property access and addEventListener, only the
addEventListener version reported a memory leak.

I see no proof or evidence
on its site that this is the case. Experienced javascript developers _know_
when leaks are created and can easily scan code for closures with circular
references in their scope chain, for example.
I think that's a rather optimistic generalisation. It may be better to
say that web developers should know how to detect memory leaks and
should test client performance thoroughly (and optimise where
necessary). Developers should also be aware of what causes memory
leaks so that they can either be avoided or cleaned up.

Since FF doesn't suffer from the same circular reference problem that IE
does, I'm not sure how this extension can reliably detect situations where
IE would leak memory.
According to Leak Monitor, you can create memory leaks using
addEventListener with Firefox, just like those in IE (though apparently
it's fixed in version 1.8, I tested in Firefox 1.5).

Does *Javascript* leak memeory, or
does the *browser* leak memory?

Javascript as a language certainly cannot leak memory, because there is no
way to manually allocate and deallocate memory. Since it is garbage
collected, it's up to the host environment to worry about cleaning up
memory. So, it's the browser's implementation of javascript that would cause
a memory leak.
ACK.
--
Rob

Oct 3 '06 #3

P: n/a
VK
Javascript as a language certainly cannot leak memory,
because there is no way to manually allocate and
deallocate memory.
If Java-like memory management systems would exclude memory leaking as
such: the world would program on nothing but Java long ago :-)

Such systems can perfectly leak as well, the difference is in the
mechanics and in the definition itself of "leaked memory". We can
compare C-like memory management and Java-like memory management
respectively with the garbage removal in a building and in a private
house. In a flat we put all trash into trash can and manually dump it
into collector. The question of "when the trash will be removed?" has
no application to the situation: it is removed at the moment of
dumping. In a private house there is a "garbage day" each week when we
have to place our container at the right place at the right position.
We cannot tell for sure when the track will come: at 6am, 7am or
afternoon. The only thing that should bother us is to place the
container properly. If it is placed properly, it will be eventually
emptied up sometime during the trash pickup day.
It seems that many C-ground programmers just refuse to fully accept
such memory management. Theoretically they know about it, but as soon
as it comes to the practical development they just come back to what
they used to. This is why I guess 99% of "memory monitoring" software
for javascript is written from C positions and therefore 100% useless
for javascript.

In javascript memory management is *automated* which means that lesser
you put your sneeky hands into it - better it works :-)) :-|

It also impossible to have a leak with fully dereferened objects. They
may remain in the memory for uncertain period of time but it is not a
leaked memory. A memory leak occurs then Garbage Collector cannot mark
a scavenger as free for removal: which means that despite the program's
author may think the opposite, there is at least one reference left
somewhere to this object. The "circular reference leak" in IE is a
classical sample of such situation.
>From the explicit memory management actions I can name only one:
dereferencing of an unused object by either setting it to null or by
using delete operator. (Important: setting a reference to undefined
value doesn't free the reference: it will remain a valid reference with
a valid explicitly assigned value). If all references to the object are
removed ("trash container is placed into the right position in front of
the house"): then in the next scan Garbage Collector will mark the
relevant scavenger (internal representation of the object) as garbage
collection available. Garbage Collector works in a "double stage" mode:
i) on the first stage it marks unused scavengers, ii) on the second
stage it actually destroys the heaps. Depending on available free
memory, intensity of the program process etc. the second stage may
happen a minute or an hour later: or it will never happen at all until
exit: if available memory is big and/or memory usage remains low. That
is NORMAL, that is OK, that was made this way for maximum optimization
(I feel like scream it out loud sometimes :-)

In Java itself you can *ask* the system to expedite the process by
using System.gc() method. It doesn't enforce the garbage collection, it
only trigs free memory check and it removes the garbage *if* the free
memory level is getting low. So most of the time System.gc() does
nothing useful except bringing a false feeling of peace to the
programmer who uses it.

JScript (but not other javascript versions AFAIK) can be more rude: by
using undocumented CollectGarbage() method you can *enforce* an
immediate removal of all scavengers marked as free to remove. But why
would you need it in a practical application? Are we so terribly short
on memory to sacrifice the execution speed for 100Kb - 500Kb ?

Internal invocation in javascript (at least in JScript) is made as
simple as a moo-cow: there are not any virtual table bindings and
dispid's are not cached. It means that in the code like:
for (var i=0; i<10000; ++i) {
foobar.foo.bar();
}
the dispatcher will request 10000 times a reference to the object
matching "foobar.foo.bar" string in the names table. That may seem as
ineffective, but it allows to keep the engine small and clean and it
allows many nice javascript'ish things like a function referencing
other function which doesn't exists yet at the moment of referencing.
In application to the memory management it means once again that you
have neither tasks nor worries but deference unused objects properly:
if you have objects needed at the beginning and never needed anymore
from some point to the end. If you have not such objects, then you can
do your best for the memory management by *doing nothing* and by
letting the automation to make the job for you.

Used memory growth by itself is *meaningless* in Java-like memory
systems. It can use say 9Mb out of allowed 10Mb while doing foo = 2 *
2; - and at the next moment it will start doing matrix transformations
and the memory usage will fail to 100Kb.

Oct 3 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.