Question

A little background

I’m developing a large-scale JS app with ExtJS3. At runtime, the user may open and close numerous widgets, thus possibly increasing memory usage. I fixed many memory holes using Chrome’s heap analyzer, but in certain cases I just can’t find the culprit. The heap analyzer shows something like GCRoot[1234]->store.items, and I can’t find the code section where the store would be referenced.

The question

What’s the exact runtime conditons under which V8 (or any other JS engine) would create a new garbage collector root? Are there certain code patterns (closure, eval, event listetes, …) that force it?

Answer 1

GC roots are the special group of objects that are used by the garbage collector as a starting point to determine which objects are
eligible for garbage collection. A “root” is simply an object that the
garbage collector assumes is reachable by default, which then has its
references traced in order to find all other current objects that are
reachable. Any object that is not reachable through any reference
chain of any of the root objects is considered unreachable and will
eventually be destroyed by the garbage collector. In V8, roots consist
of objects in the current call stack (i.e. local variables and
parameters of the currently executing function), active V8 handle
scopes, global handles, and objects in the compilation cache.

via http://zetafleet.com/blog/google-chromes-heap-profiler-and-memory-timeline

Q: What comprises GC roots?

A: Many things:

• built-in object maps;
• symbol table;
• stacks of VM threads;
• compilation cache;
• handle scopes;
• global handles.

via http://code.google.com/chrome/devtools/docs/heap-profiling.html