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.
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?
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With