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

How to track memory usage?

P: n/a
Hi
I have a JS program that runs localy (under IE6 only) on a PC but it has
a memory leak (probably the known MS one!)

What applications are there that I could use to look at the memory usage of
each object within my JS app to help locate my problem?

Thanks

Feb 27 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
I doubt there are any, but I would start with the publisher of each
browser you are supporting. They each would maintain their own tools,
if there are any. So visit Microsoft's site (for Internet Explorer)
and visit Mozilla for theirs.

Feb 27 '06 #2

P: n/a
VK

Adrian wrote:
Hi
I have a JS program that runs localy (under IE6 only) on a PC but it has
a memory leak (probably the known MS one!)
How do you define "memory leak"? You browser goes on blue screen after
certain time? After certain time your interface gets too slow? You
cannot open certain applications / files while IE is running? (just
used memory growth is not qualified for memory leak).
What applications are there that I could use to look at the memory usage of
each object within my JS app to help locate my problem?


Well, you may start with Start > Accessories > System Tools > System
Monitor. On download.com you can find more sophisticated tools. I'm
using RAM Idle for common purposes
<http://www.pcworld.com/downloads/file_description/0,fid,7604,00.asp>
(but never bother to look at it for JScript / JavaScript).

You can also download one year free trial of Visual Studio 2005 Express
<http://msdn.microsoft.com/vstudio/express/vwd/> to have more memory
tracking tools than you ever really needed :-)

But again: before to fight the ennemy it would be nice to check that he
exists ;-)

Feb 27 '06 #3

P: n/a
hi
"But again: before to fight the enemy it would be nice to check that he
exists"

I'm sure the enemy is within! probably a circular reference but its a lot of
code! the issue is the memory shown as in use by system monitor goes up each
time the app is used.

What I was hoping for is a monitor that would say these objects have been
created and are X in size, so I know where to look!

thanks...

"VK" <sc**********@yahoo.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...

Adrian wrote:
Hi
I have a JS program that runs localy (under IE6 only) on a PC but it
has
a memory leak (probably the known MS one!)


How do you define "memory leak"? You browser goes on blue screen after
certain time? After certain time your interface gets too slow? You
cannot open certain applications / files while IE is running? (just
used memory growth is not qualified for memory leak).
What applications are there that I could use to look at the memory usage
of
each object within my JS app to help locate my problem?


Well, you may start with Start > Accessories > System Tools > System
Monitor. On download.com you can find more sophisticated tools. I'm
using RAM Idle for common purposes
<http://www.pcworld.com/downloads/file_description/0,fid,7604,00.asp>
(but never bother to look at it for JScript / JavaScript).

You can also download one year free trial of Visual Studio 2005 Express
<http://msdn.microsoft.com/vstudio/express/vwd/> to have more memory
tracking tools than you ever really needed :-)

But again: before to fight the ennemy it would be nice to check that he
exists ;-)

Feb 28 '06 #4

P: n/a
VK

Adrian wrote:
I'm sure the enemy is within! probably a circular reference but its a lot of
code! the issue is the memory shown as in use by system monitor goes up each
time the app is used.
It doesn't prove anything. JScript engine uses an execution cache so
once executed blocks could be reused without extra parsing. Also as it
was pointed out JScript / JavaScript are automated memory management
languages (like Java).

So for a long lasting complicated process a *normal* memory usage
picture should be:

1) start with the required amount (100-300Kb)
2) over time (from 1min to 1hr) increase to 2-4Mb / 5-6Mb for
JScript.Net
3) after that stay on the reached level with +/- 20% fluctuations

This *normal* behavior (or the absence of such) can be observed on any
tools I mentioned in my previous post.

The extra 2-6 Mb overtime gain is not a leaked memory: these are all
kind of pre-compiled functions, 3rd libraries blocks, intermediary DOM
snapshots - briefly all kind of working stuff used for performance
optimisation.

The leak is only if:
1) You get IE alert "This process takes too many resources".
2) IE gets non-responsive / frozen
3) IE crashes with no reason
4) After you closed *all* IE instances and left your desktop for 10 min
*minumum* some strange process is still running

5) Besides that you may have DDE handler leak - so say after your
edited an Excel table over GetObject you cannot run Excel anymore or
you cannot open the same file in Excel until you exit IE.
What I was hoping for is a monitor that would say these objects have been
created and are X in size, so I know where to look!


JScript allocates memory using the relevant VBScript module (same as
for Dim myVar w/o type specification), so all variables are Variant -
of the same size and structure as in VBScript.

You still missing to say which one of five above is applicable to your
situation.
Otherwise you are just another C++'er who wants one world being ticking
by the rules of another world :-)

Feb 28 '06 #5

P: n/a
In message <dt**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Adrian
<Ad****@nospamhotmail.com.uk> writes
What applications are there that I could use to look at the memory usage of
each object within my JS app to help locate my problem?


JavaScript Memory Validator allows you to inspect the memory usage of
your JavaScript application. It only works with Mozilla though (1.0 and
1.5). If the memory leak is caused by circular references or dangling
references you forgot to clear then JSMV will show them.

http://www.softwareverify.com/javaSc...tor/index.html

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Feb 28 '06 #6

P: n/a
VK wrote:
Adrian wrote:
I'm sure the enemy is within! probably a circular reference but
its a lot of code! the issue is the memory shown as in use by
system monitor goes up each time the app is used.
It doesn't prove anything.


Given your record on recognising and labelling proof that doesn't mean
much in reality.

However, are you saying that because that is what you expect to see IE
doing? It would not surprise me as we have all seen how that
catastrophic mush that you write under the label 'JavaScript' has
cross-references so convoluted that you don't even understand the
relationships involved, and calling them 'circular' would be monumental
understatement.

Given you code I am not surprised that you would rather deny that this
issue exists; prefer to define it as something other than it is, or see
it as a misperception in others.

Didn't you learn your lesson with your defence of javascript
pseudo-protocol HREFs as completely safe and issue-free (if coded to
your satisfaction)? Indeed, have you yet recognised that the issues that
you were repeatedly told about while you blindly defended javascript
pseudo protocol HRFEs were real and significant?

The lesson there surly was that where everyone else recognises an issue
that you don't perceive at all it is you who will turn out to be
mistaken. The same is true here; the IE memory leak issue is real,
demonstrated, its cause and effect relationships certainly identified
and strategies for handling it, where necessary, designed and employed
by people who have understood what they are doing.

And I told you this last week. I realise that you are of the deluded
opinion that you know more about javascript than everyone else
contributing to this group (and don't let the constant stream of
evidence to the contrary get in the way of that delusion) but if you
elect not to believe me the least you could do is undertake some
research and see the many demonstrations of this phenomenon in action.
JScript engine uses an execution cache so once executed
blocks could be reused without extra parsing.
Another 'off the top of your head' fiction? It doesn't make sense to
talk of 'extra parsing' when javascript is required to be fully parsed
(except for - eval - and Function constructor code) and compiled into
its executable form prior to entering the global execution context.
Also as it was pointed out JScript / JavaScript are automated
memory management languages (like Java).
And JScript in IE allows the garbage collector to be explicitly
triggered through the available global - CollectGarbage - function
(rather than waiting for it to act in its own time) so it is possible to
directly test the result of JScript garbage collection on resource
allocation.
So for a long lasting complicated process a *normal* memory
usage picture should be:

1) start with the required amount (100-300Kb)
IE alone consumes considerably more memory than that.
2) over time (from 1min to 1hr) increase to 2-4Mb / 5-6Mb for
JScript.Net
3) after that stay on the reached level with +/- 20% fluctuations

This *normal* behavior (or the absence of such) can be observed
on any tools I mentioned in my previous post.

The extra 2-6 Mb overtime gain is not a leaked memory: these
are all kind of pre-compiled functions, 3rd libraries blocks,
intermediary DOM snapshots - briefly all kind of working
stuff used for performance optimisation.

The leak is only if:
1) You get IE alert "This process takes too many resources".
So a memory leak can be eliminate by increasing system resources? That
is no a logical definition of a memory leak.
2) IE gets non-responsive / frozen
3) IE crashes with no reason
There is no issue so long as code doesn't actually break the browser?
With criteria like that it is less than surprising that you write such
poor code.
4) After you closed *all* IE instances and left your desktop
for 10 min *minumum* some strange process is still running
?
5) Besides that you may have DDE handler leak - so say after your
edited an Excel table over GetObject you cannot run Excel anymore or
you cannot open the same file in Excel until you exit IE.
What I was hoping for is a monitor that would say these objects
have been created and are X in size, so I know where to look!
JScript allocates memory using the relevant VBScript module
(same as for Dim myVar w/o type specification), so all variables
are Variant - of the same size and structure as in VBScript.


Making this stuff up off the top of your head does no more than make you
look a fool.
You still missing to say which one of five above is applicable
to your situation
The above are irrelevant to anyone's situation.
Otherwise you are just another C++'er who wants one world
being ticking by the rules of another world :-)


Who are you to be criticising others? You disregard the rules that
define javascript and substitute your own tangled web of inconstant
fictions, including many notions adopted from misconceptions of other
languages.

Precedent suggests that even demonstrations of phenomena do not convince
you of their reality but in the hop that you will actually realise that
you don't know what you are talking about in this respect (at least) I
will post a demonstration of IE memory leak issue. Even if you are not
convinced at least it will leave the rational in no doubt that the issue
exists.

As some memory monitoring is not always that fine-grained the
demonstration strategy is to create an object with a string pro9perty
that is sufficiently big that un-garbage collected instances will be
evened even in tools as crude as System Monitor. The following HTML,
when loaded into IE provides 5 buttons:-

"Make Big Object" - creates an object with a large string
property, but then removes all references to that object
so it is free for garbage collection.
"Make and trap big Object" - creates the same big object
but also creates a DIV element and circular references
between the DIV and the JS object but simultaneously
clears all accessible references to the JS object and the
DIV.
"Break Circular References" - examines all DIVs and removes
any JS objects assigned to them (breaking the circular
references).
"Collect Garbage" - Runs the JScript garbage collector
immediately.
"Create Indestructible Big Object" - Creates the big object
and a DIV, with circular references between the two, but
never inserts the DIV into the DOM.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<script type="text/javascript">

function BigObject(){
var c, st = 'xxxx';
for(c = 0;c < 23;++c){
st += st; //double string size;
}
this.bulk = st;
}
BigObject.prototype.insertNode = function(){
document.body.appendChild(this.getNode());
};
BigObject.prototype.getNode = function(){
var self = this;
var div = document.createElement('DIV');
div.onclick = function(){return;};
return div;
};

function sequnce(callback, messge){
document.getElementById('out').innerText = messge;
setTimeout(callback, 40);
}

function makeBigObject(){
var temp = new BigObject();
temp = null;
document.getElementById('out').innerText =
'Object Created and References Cleared';
}
function makeTrapedBigObject(){
var temp = new BigObject();
temp.insertNode();
temp = null;
document.getElementById('out').innerText =
'Object Created with Circular References';
}
function makeIndistBigObject(){
var temp = new BigObject();
temp.getNode();
temp = null;
document.getElementById('out').innerText =
'Object Created with Isolated Circular References';

}
function breakCircles(){
var list, temp, c, len, count = 0;
if(
(list = document.getElementsByTagName('DIV'))
){
for(c = 0, len = list.length;c < len;++c){
temp = list[c];
if(temp.onclick){
temp.onclick = null;
++count;
}
}
}
document.getElementById('out').innerText =
(count +' Circular References Broken');

}
function colGarbage(){
CollectGarbage();
document.getElementById('out').innerText = 'Garbage Collected';
}
</script>
<div id="out">|||||||||</div>
<input type="button" value="Make Big Object"
onclick="sequnce(makeBigObject, 'Making Big Object');"><br>
<input type="button" value="Make and Trap Big Object"
onclick="sequnce(makeTrapedBigObject, 'Making and Trapping Big
Object')"><br>
<input type="button" value="Break Circular References"
onclick="sequnce(breakCircles, 'Breaking Circular References');""><br>
<input type="button" value="Collect Garbage"
onclick="sequnce(colGarbage, 'Collecting Garbage');"><br><br>
<input type="button" value="Create Indestructible Big Object"
onclick="sequnce(makeIndistBigObject, 'Createing Indestructible Big
Object');">
</body>
</html>

If the above page is loaded into IE with some form of memory monitor
operating clicking the "Make Big Object" button should show an evident
jump in memory consumption, but that object's references are free so the
object is immediately available for garbage collection. However, the
odds are good that IE will not garbage collect it for a while, so
clicking the "Collect Garbage" button will run the garbage collector
immediately, showing the allocated memory being returned to the system.
A similar reduction in consumed memory can also be observed by
navigating the page or re-lading the page (the implication being that
these two actions also trigger immediate garbage collection).

On the other hand clicking the "Make and trap big Object" button
increases the memory consumption but running the garbage collector will
not free this memory. And, more importantly, navigating away from the
page, or re-loading it also will not free this memory (as it does
without the circular references).

Without navigation or re-loading it is possible to click the "Break
Circular References" button ant then re-try the "Collect Garbage" button
to see that it is only the circular references that prevent the garbage
collection of the objects. And having used the "Break Circular
References" button navigation also frees the memory.

The issue here is not that the circular references prevent garbage
collection. They should as the DOM refers to the DIV so it cannot be
garbage collected, and so the JS object it refers to cannot be collected
either. The above illustrates that when the circular references are
removed the garbage collector does free the associated memory.

The issue here is rather that the circular references prevent garbage
collection when both the DIV and the JS object are unreferenceable in
the system (they refer to teach other but no external references to them
exist), even when a page is navigated away from or re-loaded. At that
point all of the objects involved, JS objects and DOM elements, become
unreferenceable and should be made available for garbage collection. But
the circular references prevent this garbage collection and the consumed
resources are never freed until IE is closed down.

The final button illustrates this issue within the same page. It creates
the big object and the DIV but it never inserts the DIV into the DOM, so
there are no available references to the JS object, and no references to
the DIV, but click the collect garbage button as much as you like and
this object will never be freed.

And that is the memory leak; consumed memory that should be expected to
be freed by garbage collected (and is in other brewer environments) is
not freed until the browser is closed down, and the cause of that
problem is circular references between DOM Elements and JS objects (of
one form or another).

Richard.
Mar 1 '06 #7

P: n/a
VK

Richard Cornford wrote:
Given your record on recognising and labelling proof that doesn't mean
much in reality.
<snip>
And JScript in IE allows the garbage collector to be explicitly
triggered through the available global - CollectGarbage - function
(rather than waiting for it to act in its own time) so it is possible to
directly test the result of JScript garbage collection on resource
allocation.


<snip>
JScript allocates memory using the relevant VBScript module
(same as for Dim myVar w/o type specification), so all variables
are Variant - of the same size and structure as in VBScript.


Making this stuff up off the top of your head does no more than make you
look a fool.


<snip>

You should get used by now that when VK speaks in such affurmative tone
(without IMHO, AFAIK etc.) it means that he provides some verified
facts, not something "off the top of his head".

<http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx>
<quote>
very now and then the garbage collector runs. First it puts a "mark"
on every object, variable, string, etc - all the memory tracked by
the GC. (JScript uses the VARIANT data structure internally and there
are plenty of extra unused bits in that structure, so we just set one
of them.)
</quote>

Every other fact I mentioned can be also found on MSDN - one just needs
a will to search.

And I'd like to repeat that 90% of so called "memory leaks" caused by
misconception of how the automated memory management works. It doesn't
mean at all that that memory leaks in JScript / JavaScript do not
exists - of course they do. But still it is a very common situation
when some C++'er sets the last reference to undefined and runs to look
at the momory monitor right away. Naturally the heap is still there and
can stay there for God knows how long. But our C++'er assumes that she
just did ~constructor (which she did not because she cannot). So right
away a panic arount: "I have a memory leak!". :-)

I wouldn't be so pictural if I did not see exactly the same behavior
for years in comp.java... groups. The same false "memory leak" alarms,
the same custom made "destructors" using system.gc() - which haturally
do not destruct anything.

This is what I said: do not force the rules of one schema on another
schema. Instead learn to live by new rules. :-)

One more quote from the same article:

The opposite problem is that perhaps a GC will not run when you want
one to. If you say "blah = null" then the memory owned by blah will
not be released until the GC releases it. If blah is the sole remaining
reference to a huge array or network of objects, you might want it to
go away as soon as possible. Now, you can force the JScript garbage
collector to run with the CollectGarbage() method, but I don't
recommend it. The whole point of JScript having a GC is that you don't
need to worry about object lifetime. If you do worry about it then
you're probably using the wrong tool for the job!

Mar 1 '06 #8

P: n/a
VK wrote:
Richard Cornford wrote:
Given your record on recognising and labelling proof that
doesn't mean much in reality. <snip>
JScript allocates memory using the relevant VBScript
module (same as for Dim myVar w/o type specification),
so all variables are Variant - of the same size and
structure as in VBScript.
Making this stuff up off the top of your head does no more
than make you look a fool.

<snip>

You should get used by now that when VK speaks in such
affurmative tone (without IMHO, AFAIK etc.) it means
that he provides some verified facts, not something
"off the top of his head".


Here do we have another example of your divergent definition of 'proof'?
Considering that you have posted:-

| <script type="text/javascript">
| void function dummy(args) {
| alert('Booh!');
| }
|
| window.onload = dummy;
|
| ...
|
| Function dummy is being parsed and allocated on script load,
| but void operator prevents the script context to get a reference
| on the allocated memory heap. So it becomes garbage collector
| ready right away.

- without any weasel-words do I take it hat this represents "provides
some verified facts"? It is of course an utterly untrue fiction that
could have originated nowhere but in you deranged imagination.

And with that standard of 'verified fact' and 'proof' I cannot be
surprised to read:-
<http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx>
<quote>
very now and then the garbage collector runs. First it puts
a "mark" on every object, variable, string, etc - all the memory
tracked by the GC. (JScript uses the VARIANT data structure
internally and there are plenty of extra unused bits in that
structure, so we just set one of them.)
</quote>
One of the many reasons for you ongoing misconception of javascript is
your tendency to take conversational and explanatory text as definitive.
Another is your habit of miss-reading those texts and seeing them as
saying something other than what they actually do say. That text
absolute does not say that "JScript allocates memory using the relevant
VBScript module" or that "all variables are Variant - of the same size
and structure as in VBScript". The first is self-evidently false as to
be true there would be a dependency of JScript upon VBScript, and so if
VBScritp were removed form a Windows installation JScript would become
non-functional; which is not the case. The only suggestion of the second
is a naming coincidence between a structure called "VARIANT" employed in
the implementation of JScript and a Variant type in VBScript.

Reading in what is not said does not make what is not said true.
Every other fact I mentioned can be also found on MSDN -
one just needs a will to search.
As that 'fact' was not supported by your quoted text I would expect
every other example of what you perceive as supporting your other
'facts' to be equally misinterpreted. So there would be no point looking
for such 'facts' as they are likely to be as fictional as the first.
Experience suggests that it is considerably more efficient to assume
that you are talking nonsense and leave it to you to try to back up your
baseless and irrational claims.
And I'd like to repeat that 90% of so called "memory leaks"
caused by misconception of how the automated memory management
works.
Given that you said:-

| The leak is only if:
| 1) You get IE alert "This process takes too many resources".
| 2) IE gets non-responsive / frozen
| 3) IE crashes with no reason
| 4) After you closed *all* IE instances and left your desktop
| for 10 min *minumum* some strange process is still running
|
| 5) Besides that you may have DDE handler leak - so say after
| your edited an Excel table over GetObject you cannot run
| Excel anymore or you cannot open the same file in Excel until
| you exit IE.

- you will have to excuse me if I regard your attribution of cause to
the identification of leaks with the same incredulity as the rest of
what you say.
<snip> This is what I said: do not force the rules of one schema
on another schema. Instead learn to live by new rules. :-)

<snip>

And yet you have repeatedly tried to read the rules of some class-based
conception of javascript into javascript, regardless of how
self-evidently unsuccessful that reading has proved.

Richard.
Mar 1 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.