For now, some subsystems only work if Chrome is started with the --no-sandbox
flag.
After recording a trace, you will see the timeline view. Timeline view shows:
Click one of the dots to bring up the analysis view. Click on a cell in analysis view to reveal more information about its subsystem. PartitionAlloc for instance, has more details about its partitions.
The purple dots represent heavy dumps. In these dumps, components can provide more details than in the regular dumps. The full details of the MemoryInfra UI are explained in its design doc.
Columns in blue reflect the amount of actual physical memory used by the process. This is what exerts memory pressure on the system.
Columns in black reflect a best estimation of the the amount of physical memory used by various subsystems of Chrome.
malloc
, or new
for most non-Blink objects.The tracing column in gray reports memory that is used to collect all of the above information. This memory would not be used if tracing were not enabled, and it is discounted from malloc and the blue columns.
Another memory profiler? What is wrong with tool X? Most of the existing tools:
MemoryInfra leverages the existing tracing infrastructure in Chrome and provides contextual data:
__gnu_cxx::new_allocator< std::_Rb_tree_node< std::pair< std::string const, base::Value*>>> ::allocate
.GYP_DEFINES
, no time-consuming symbolizations stages. All the logic is already into Chrome, ready to dump at any time.MemoryInfra is based on a simple and extensible architecture. See the slides on how to get your subsystem reported in MemoryInfra, or take a look at one of the existing examples such as malloc_dump_provider.cc. The crbug label is Hotlist-MemoryInfra. Don't hesitate to contact tracing@chromium.org for questions and support.
Architectural:
Chrome-side design docs:
Catapult-side design docs: