UPDATE: I found Yury's response to be superior.

In my opinion, there is no memory leak issue. The positive slope observed is simply a result of setInterval and setTimeout functions. The garbage collection process is still effective, indicated by the sawtooth patterns, which means there is technically no memory leak (I believe).

I cannot identify a solution to address this so-called "memory leak." In this context, it refers to each call to setInterval causing an increase in memory usage, evident from the upward slopes in the memory profiler.

The truth is, there isn't a genuine memory leak occurring; the system successfully releases the allocated memory. A memory leak occurs when a program fails to return memory back to the operating system.

The memory profiles depicted below demonstrate that a memory leak is not happening. With every function invocation, memory usage grows. Although the same function is called repeatedly, the memory does accumulate before being collected, creating the sawtooth pattern.

I've experimented with different ways to adjust the intervals, yet they consistently lead to the same sawtooth pattern (some attempts resulted in retained references preventing garbage collection).

function doIt() {
    console.log("hi")
}

function a() {
    doIt();
    setTimeout(b, 50);
}
function b() {
    doIt();
    setTimeout(a, 50);
}

a();

http://fiddle.jshell.net/QNRSK/14/

function b() {
    var a = setInterval(function() {
        console.log("Hello");
        clearInterval(a);
        b();                
    }, 50);
}
b();

http://fiddle.jshell.net/QNRSK/17/

function init()
{
    var ref = window.setInterval(function() { draw(); }, 50);
}
function draw()
{
    console.log('Hello');
}
init();

http://fiddle.jshell.net/QNRSK/20/

function init()
{
    window.ref = window.setInterval(function() { draw(); }, 50);
}
function draw()
{
    console.log('Hello');
    clearInterval(window.ref);
    init();
}
init();​

http://fiddle.jshell.net/QNRSK/21/

It seems that setTimeout and setInterval are not officially part of JavaScript (hence not included in v8). Their implementation varies among developers. You may want to examine the implementation of setInterval and related functions in node.js

The issue at hand does not lie in the code itself, as it is not leaking memory. Rather, the problem stems from how the Timeline panel has been implemented. As Timeline records events, it gathers JavaScript stack traces for each invocation of setInterval callback. Initially, the stack trace is stored in the JS heap and then copied into native data structures. Once the stack trace is transferred to the native event, it no longer serves a purpose in the JS heap and becomes garbage. This process is what causes the fluctuations on the memory graph. By disabling the specific call mentioned at this link, the memory graph remains stable.

It's worth noting that there is a known bug associated with this issue, which can be found at: this address

When a function is called in JavaScript, a stack frame is created each time. Different from many other programming languages, JavaScript stores the stack frames on the heap along with everything else. This means that with every function call, which occurs approximately every 50 milliseconds, a new stack frame is added to the heap. Over time, these accumulated stack frames are eventually garbage collected.

This process is somewhat inevitable due to how JavaScript operates. The best way to address this issue is by making the stack frames as small as possible, a practice that most implementations are likely already utilizing.

In response to your mention of setInterval causing flickering:

I've observed that using setInterval(), setTimeout(), and even requestAnimationFrame can lead to memory allocation without explicit request, resulting in frequent garbage collection calls. More GC calls mean more flickers :-(

You may want to consider replacing setInterval with a more efficient self-invoking function based on setTimeout. This approach is highlighted by Paul Irish in his talk "10 things I learned from the jQuery source" (video available here, notes here at #2). Essentially, you replace the setInterval call with a function that invokes itself indirectly through setTimeout after completing its intended task. As mentioned in the talk:

Many argue that setInterval is not ideal as it continues calling a function at set intervals regardless of whether the function has finished executing or not.

To modify the code snippet provided above, you could update your init function like this:

function init()
{
     //initialize variables
     
     //execute awesome code

     //start rendering
     drawLoop();
}

function drawLoop()
{
   //perform necessary tasks
   draw();

   //schedule further work
   setTimeout(drawLoop, 50);
}

This adjustment should be beneficial because:

1. draw() will only be called again once the rendering loop has completed its current operation
2. as other responses have pointed out, the continual firing of functions by setInterval does add strain on the browser
3. debugging becomes easier without being constantly interrupted by setInterval triggers

I hope this suggestion proves helpful!

It appears that Chrome is not under much memory pressure from your program (1.23 MB is considered low memory usage in today's standards), so the garbage collector may not be triggered aggressively. If you increase the memory usage of your program, you will likely see the garbage collector kick in. You can try modifying your code like this:

<!html>
<html>
<head>
<title>Where does memory go?</title>
</head>
<body>

Hello!

<script>
function initialize()
{
    var reference = window.setInterval(function() { render(); }, 50);
}

function render()
{
    var array = new Array();
    for (var j = 0; j < 1e6; ++j) {
        array.push(Math.random());
    }
    return true
}

initialize();
</script>

</body>
</html>

Upon running this code, I observed a saw tooth pattern in memory usage, reaching approximately 13.5MB (which is still relatively small by today's standards).

PS: Here are some details about my browser:

Google Chrome   23.0.1271.101 (Official Build 172594)
OS  Mac OS X
WebKit  537.11 (@136278)
JavaScript  V8 3.13.7.5
Flash   11.5.31.5
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11

Experiment with removing the anonymous function in your code. Here's an alternative approach:

function render()
{
    return true;
}

function setup()
{
    var timer = window.setInterval(render, 50);
}

Notice any differences in behavior?

No signs of a memory leak are present here. As long as the memory usage decreases after garbage collection, and the overall trend of memory usage doesn't increase over time, there is no indication of a leak.

The intriguing aspect to consider is that the setInterval function does utilize memory during its operation, despite appearing not to allocate anything. In reality, it does require some allocations:

1. Stack space is allocated for executing both the anonymous function and the draw() routine.
2. It may or may not need to allocate temporary data for performing the calls themselves.
3. A small amount of storage is allocated to hold the return value from draw().
4. Internally, setInterval could allocate additional memory to reschedule a recurring event (depending on how it functions internally).
5. The Just-In-Time compiler might trace the method, resulting in more memory allocation for the trace and related metrics. If identified as "hot" by the VM, more memory could be allocated to hold the compiled machine code, potentially reducing average memory usage in most cases.

Memory gets allocated every time the anonymous function runs, leading to periodic GC cycles to clean up and maintain a base level of memory usage. This cycle repeats until the function is stopped, which is considered normal behavior.

Encountering a similar issue, a client informed me that their computer's memory was steadily increasing. Initially perplexed by how a web app could cause this through a simple browser, I discovered the problem only occurred in Chrome.

To investigate further, I collaborated with a colleague and utilized Chrome's developer tools and task manager to observe the reported memory increase.

We identified a jquery function (request animation frame) repeatedly loading and causing the memory spike. Delving deeper, we realized a jquery countdown feature was the culprit as it contained a "SETINTERVAL" function continuously updating dates on my app's layout.

Working within ASP.NET MVC, I removed the problematic jquery script from BundleConfig and replaced the time countdown with the following code in my layout:

@(DateTime.Now.ToString("dd/MM/yyyy HH:mm"))

I encountered a similar problem discussed in this post. Despite trying various ways of utilizing setTimeout or setInterval, the issue persists.

The solution lies in extending the interval time of setTimeout or setInterval to give the JavaScript engine room to 'breathe', as the Garbage Collection principle is typically activated during downtimes when the engine is not busy.

A quick reference: JavaScript operates mainly on a single thread, leading to execution of code in a sequential manner.

For additional insights, please refer to my discussion found here.