wrong

1. Pass function as a reference: setInterval(function() { doSomething(); }, 10);

2. Pass an expression as a string: setInterval("doSomething();", 10);

those two are equal , this is not

1. Pass function as a stored reference:

var f=function() { doSomething(); };

var hp=setInterval(f, 10);

...window.clearINterval(f);

or

clearINterval(hp);

These are out of topic

you keep arguing how to use setInterval which is a trivial thing for me ..

anyway, it just looks stupid that the garbage collector have that zigzag pattern at all

what memory does it allocate ? it uses one global variable and that's all

I didn't even declare a new variable.

This is strange indeed

anyway, it just looks stupid that the garbage collector have that zigzag pattern at all

what memory does it allocate ? it uses one global variable and that's all
I didn't even declare a new variable.

This is strange indeed

1. garbage source.

While your example program itself does not visibly generate garbage - there still are plenty of garbage sources, a'la: virtual machine interpreting the javascript, jit compilation, whatever other internal structs it needs to implement the used or assumed to be used functionality of javascript.

Case in point of a possible source: calling a function needs a local scope/closure to be created and destroyed (technically - a good jit optimizer under specific conditions can prevent it from using generic GC for cleanup).

2. zigzag pattern.

Garbage collection is an overhead (ie. in a sense no useful work is done - GC is hardly the goal of any program ). Hence GC implementations avoid actually doing it if they do not need to do it (ie. there is plenty of free memory) - allowing memory usage to steadily grow till it finally decides to do the work causing a sudden drop in memory usage => zigzag.

edit:

it seems to leak according to chrome dev tools

I have not used chrome dev tools, but i guess you are misinterpreting what it tells you.

I don't think this is a case of circular dependencies or anything to do with DOM

Yep. However, memory is not free till GC tells so => every unused crumb of memory piles up over time till GC gets rid of them all, all at once.

is this normal in javascript ?

Yes. It is common in all languages that heavily use mark-and-sweep style GC, not just javascript.

One might have a leak problem if memory usage grows over GC cycles (ie zigzag bottom line keeps growing).

, true that.



(sorry for being a jackass - i am just easily amused)

Ok thanks for all the reply,,

I get it now,

I never pay attention to GC mechanism before

since in python ( the other intepreted language I know ever used ) the memory doesn't seem to have this sawtooth

I directly assume that it's a leak when I saw that

so "sawtooth" is normal in javascript

btw, how do you announce this thread as solved ?

1. Pass function as a reference: setInterval(function() { doSomething(); }, 10);

2. Pass an expression as a string: setInterval("doSomething();", 10);

again, this generates a total leak! For the parameter is stored smartly in object that setInterval returns, but you do not store this returned object. and the reference to parameter that gets allocated in expresion gets uncought. You can afford not storing the retuned object only if you pass an allocated function reference! You are all here trying to get experts in javascript finding out I am writing correct informations.

again to make it clear , though I am getting sick of you

var tm=setInterval(function(){alert('');},100) ;// does not generate leak

setInterval(function(){alert('');},100) ; // generates total leak

var func=function(){alert('');};

setInterval(func,100) ; // does not generate leak

I have also said that those given 2 ways you described are interpreted by JIT compiler as totaly the same, what is totaly true information, but it got willingly downvoted automaticly. This very invalidates the potential of this portal, that any dumb 15 year old expert can just do what his low selfesteem needs to.