This document describes the architecture for the profiling process, which tracks memory allocations in other processes. See design doc for more details.
There is some additional information in //chrome/common/profiling/README.md
chrome://flags/#memlog and set the flag to “Profile only the browser process.” It's possible to profile all processes, but that has a higher performance impact, and heap dumps of renderer processes are less actionable.
By default, you don‘t need to do anything. The heap profiler will detect when the browser’s memory usage has exceeded a certain threshold and upload a trace.
Due to size constraints, most allocations are pruned from the heap dump. Only allocations of sufficient size and/or frequency are kept. After pruning, the result is ~100x smaller, but still accounts for about half of all allocations. More importantly, it still accounts for all obvious memory leaks.
When profiling is enabled, the browser process will spawn the profiling service. The services lives in a sandboxed, utility process, and its interface is at
All other processes, including the browser process, are ProfilingClients. See
profiling_client.mojom. Depending on the profiling mode, the browser process will start profiling for just itself and the GPU process [
--memlog=minimal], or itself and all child processes [
The browser process creates a pipe for each ProfilingClient that allows the client processes to communicate memory events to the profiling process.
//chrome/common/profiling - Logic for ProfilingClient.
//chrome/browser/profiling_host - Logic in browser process for starting profiling service, and connecting ProfilingClients to the profiling service.
//chrome/profiling - Profiling service.