paulirish
commented
9 years ago a few more notes from a Q&A thread.
Allocation Tracker name doesn't exactly matches with the tool because it doesn't track allocations, but alive objects. I think Object Tracker sounds better.
- How/When is garbage collected? In the heap profiler, a full GC happens before every snapshot. Does the "Allocation Tracker" do the same thing (that's a lot of GCs!)?
Object tracker iterates through js heap. In v8 the iteration process requires full GC by design. So each time when Object tracker does the job, it forces full gc, gets an iterator and iterates through the heap. As a result of that it obtains the information about live objects in the heap, the new objects get new ids. After that Object tracker compares the information about live objects against the information from the previous run and sends the delta to devtools front-end.
Thereby it can't detect how many objects were allocated due to the fact that it forces gc, but it could say how many new objects were born since the previous run and still live.
Also it keeps identity for the objects, so it could say that some old objects died.
- How often are the snapshots taken? (I heard 50ms, is that accurate?)
Backend uses a 50ms timer but the timer can't interrupt js or native code. Also the heap might be quite big, so the gc and scan processes also could take a long time. As a result we have no guaranties about the time and the frequency but object tracker records the timestamp for the each run. So front-end could position the bars precisely.
- Each vertical bar at the top shows an allocation. I assume the height of the bars are relative to the amount of memory allocated in each snapshot?
You almost right, each bar shows the total size of the new objects that were found at that moment in time. Yes, the height is relative to the size.
- Blue portion of the bar corresponds to allocations that are still live in the heap at the time the profile is stopped. Gray portion of the bar corresponds to allocations that have been GCed at the time the profile is stopped. Correct?
yes, exactly. s/allocations/objects/g there and in all other places.
- Is the eventual plan to show a running timeline while the snapshot is being collects (like in the Timeline?) In my initial use, it was tricky to correlate which allocation corresponded to the actions I took while collecting the snapshot. I like the visual cues the Timeline gives while collecting the trace.
Yep, there is a patch about that. But it is not landed yet. https://codereview.chromium.org/14639004/
addyosmani
watch this:
Instructions to use heap allocation profiler
The allocation profiler takes heap snapshots periodically throughout the recording (as frequently as every 50 ms!) and one final snapshot at the end of the recording.
The bars at the top indicate when new objects are found in the heap. The height of each bar corresponds to the size of the recently allocated objects, and the color of the bars indicate whether or not those objects are still live in the final heap snapshot: blue bars indicate objects that are still live at the end of the timeline, gray bars indicate objects that were allocated during the timeline, but have since been garbage collected.
In the example above, an action was performed 10 times. The sample program caches five objects, so the last five blue bars are expected. But the leftmost blue bar indicates a potential problem. You can then use the sliders in the timeline above to zoom in on that particular snapshot and see the objects that were recently allocated at that point. Clicking on a specific object in the heap will show its retaining tree in the bottom portion of the heap snapshot. Examining the retaining path to the object should give you enough information to understand why the object was not collected, and you can make the necessary code changes to remove the unnecessary reference.
Record heap allocation timeline
See allocated memory by function
references