As of Chrome 48, MemoryInfra supports heap profiling. Chrome will track all live allocations (calls to new or malloc without a subsequent call to delete or free) along with sufficient metadata to identify the code that made the allocation.
By default, MemoryInfra traces will not contain heap dumps. Heap profiling must be enabled via chrome://memory-internals or about://flags.
[TOC]
- Navigate to chrome://memory-internals.
- There will be an error message at the top if heap-profiling is not supported on the current configuration
- Enable heap profiling for the relevant processes. Future allocations will be
tracked. Refresh the page to view tracked processes.
- To enable tracking at process start, navigate to chrome://flags and search
for
memlog.
- To enable tracking at process start, navigate to chrome://flags and search
for
- To take a heap dump, click
save dump. This is stored as a MemoryInfra trace. - To symbolize the trace:
- Windows only: build
addr2line-pdbfrom the chromium repository. For subsequent commands, add the flag--addr2line-executable=<path_to_addr2lin-pdb> - If this is a local build, run the command
./third_party/catapult/tracing/bin/symbolize_trace --is-local-build <path_to_trace> - If this is an official Chrome build, run
./third_party/catapult/tracing/bin/symbolize_trace <path_to_trace>. This will request authentication with google cloud storage to obtain symbol files [googlers only]. - If this is an official macOS or Linux Chrome build, add the flag
--use-breakpad-symbols. - If the trace is from a different device, add the flag
--only-symbolize-chrome-symbols.
- Load the (now symbolized) trace in chrome://tracing.
To obtain native heap dumps, you will need a custom build of Chrome with the GN
arguments enable_profiling = true, arm_use_thumb = false and
symbol_level=1. All other steps are the same.
Alternatively, if you want to use an Official build of Chrome, navigate to
chrome://flags and set memlog-stack-mode to pseudo. This will provide
less-detailed stacks. The stacks also don't require symbolization.
For the most part, the setting enable-heap-profiling in chrome://flags has a
similar effect to the various memlog flags.
-
Select a heavy memory dump indicated by a purple
dot.
-
In the analysis view, cells marked with a triple bar icon (☰) contain heap dumps. Select such a cell.
-
Scroll down all the way to Heap Details.
-
To navigate allocations, select a frame in the right-side pane and press Enter/Return. To pop up the stack, press Backspace/Delete.
-
Run
python ./third_party/catapult/experimental/tracing/bin/diff_heap_profiler.py <path_to_trace> -
This produces a directory
output, which contains a JSON file. -
Load the contents of the JSON file in any JSON viewer, e.g. jsonviewer.
-
The JSON files shows allocations segmented by stacktrace, sorted by largest first.
The heap details view contains a tree that represents the heap. The size of the root node corresponds to the selected allocator cell.
*** aside The size value in the heap details view will not match the value in the selected analysis view cell exactly. There are three reasons for this. First, the heap profiler reports the memory that the program requested, whereas the allocator reports the memory that it actually allocated plus its own bookkeeping overhead. Second, allocations that happen early --- before Chrome knows that heap profiling is enabled --- are not captured by the heap profiler, but they are reported by the allocator. Third, tracing overhead is not discounted by the heap profiler.
The heap can be broken down in two ways: by backtrace (marked with an ƒ), and by type (marked with a Ⓣ). When tracing is enabled, Chrome records trace events, most of which appear in the flame chart in timeline view. At every point in time these trace events form a pseudo stack, and a vertical slice through the flame chart is like a backtrace. This corresponds to the ƒ nodes in the heap details view. Hence enabling more tracing categories will give a more detailed breakdown of the heap.
The other way to break down the heap is by object type. At the moment this is only supported for PartitionAlloc.
*** aside In official builds, only the most common type names are included due to binary size concerns. Development builds have full type information.
To keep the trace log small, uninteresting information is omitted from heap
dumps. The long tail of small nodes is not dumped, but grouped in an <other>
node instead. Note that although these small nodes are insignificant on their
own, together they can be responsible for a significant portion of the heap. The
<other> node is large in that case.
In the trace below, ParseAuthorStyleSheet is called at some point.
The pseudo stack of trace events corresponds to the tree of ƒ nodes below. Of
the 23.5 MiB of memory allocated with PartitionAlloc, 1.9 MiB was allocated
inside ParseAuthorStyleSheet, either directly, or at a deeper level (like
CSSParserImpl::parseStyleSheet).
By expanding ParseAuthorStyleSheet, we can see which types were allocated
there. Of the 1.9 MiB, 371 KiB was spent on ImmutableStylePropertySets, and
238 KiB was spent on StringImpls.
It is also possible to break down by type first, and then by backtrace. Below
we see that of the 23.5 MiB allocated with PartitionAlloc, 1 MiB is spent on
Nodes, and about half of the memory spent on nodes was allocated in
HTMLDocumentParser.
Heap dump diffs are fully supported by trace viewer. Select a heavy memory dump (a purple dot), then with the control key select a heavy memory dump earlier in time. Below is a diff of theverge.com before and in the middle of loading ads. We can see that 4 MiB were allocated when parsing the documents in all those iframes, almost a megabyte of which was due to JavaScript. (Note that this is memory allocated by PartitionAlloc alone, the total renderer memory increase was around 72 MiB.)