How can I determine what objects are being collected by the garbage collector?

Question

I have significant garbage collection pauses. I\'d like to pinpoint the objects most responsible for this collection before I try to fix the problem. I\'ve looked at the hea

Answer 1

In chrome profiles takes two heap snapshots, one before doing action you want to check and one after.

Now click on second snapshot.

On the bottom bar you will see select box with option "summary". Change it to "comparision".

Then in select box next to it select snaphot you want to compare against (it should automaticaly select snapshot1).

As the results you will get table with data you need ie. "New" and "Deleted" objects.

Answer 2

If you're trying to choose between a few likely culprits, you could modify the object definition to attach themselves to the global scope (as list under document or something). Then this will stop them from being collected. Which may make the program faster (they're not being reclaimed) or slower (because they build up and get checked by the mark-and-sweep every time). So if you see a change in performance, you may have found the problem.

One alternative is to look at how many objects are being created of each type (set up a counter in the constructor). If they're getting collected a lot, they're also being created just as frequently.

Answer 3

Take a look at https://developers.google.com/chrome-developer-tools/docs/heap-profiling

especially Containment View

The Containment view is essentially a "bird's eye view" of your application's objects structure. It allows you to peek inside function closures, to observe VM internal objects that together make up your JavaScript objects, and to understand how much memory your application uses at a very low level.

The view provides several entry points:

DOMWindow objects — these are objects considered as "global" objects for JavaScript code; GC roots — actual GC roots used by VM's garbage collector; Native objects — browser objects that are "pushed" inside the JavaScript virtual machine to allow automation, e.g. DOM nodes, CSS rules (see the next section for more details.) Below is the example of what the Containment view looks like:

Answer 4

With newer Chrome releases there is a new tool available that is handy for this kind of task:

The "Record Heap Allocations" profiling type. The regular "Heap SnapShot" comparison tool (as explained in Rafał Łużyński answers) cannot give you that kind of information because each time you take a heap snapshot, a GC run is performed, so GCed objects are never part of the snapshots. However with the "Record Heap Allocations" tool constantly all allocations are being recorded (that's why it may slow down your application a lot when it is recording). If you are experiencing frequent GC runs, this tool can help you identify places in your code where lots of memory is allocated. In conjunction with the Heap SnapShot comparison you will see that most of the time a lot more memory is allocated between two snapshots, than you can see from the comparison. In extreme cases the comparison will yield no difference at all, whereas the allocation tool will show you lots and lots of allocated memory (which obviously had to be garbage collected in the meantime).

Unfortunately the current version of the tool does not show you where the allocation took place, but it will show you what has been allocated and how it is was retained at the time of the allocation. From the data (and possibly the constructors) you will however be able to identify your objects and thus the place where they are being allocated.