This page surveys and organizes efforts against memory bloat in Chrome.
There are two main types of memory issues. One is memory safety
issues like use-after-free and buffer-overflow. Many tools are your friends like ASAN
and Dr. Memory
for memory safety issues. Other memory issues are memory bloat
issues that simply mean too large memory usage. We need completely different efforts and toolsets against memory bloat issues than memory safety issues.
Leaks are a part of memory bloat issue. Some leaks can be found by some memory safety tools like Dr. Memory, especially in case malloc'ed objects remain to the end. We however have many other types of practical leaks. For example, forgetting to release a reference-counted pointer to a bulk of objects may practically cause a leak. It cannot be caught as it's eventually released at the very end. Such leaks are observed by tools against memory bloat issues.
File a Bug
Efforts and Tools
Categorizing the Efforts
Memory bloat issues are complicated, and we need to observe them from various viewpoints: testing, reproducing, breaking-down, leaking... The following is a trial to categorize existing efforts. Feel free to edit the table for better categorization.
Feel free to add your efforts in the list. The description is nice to have its advantage and also DISADVANTAGE (limitation) so that we can easily understand what is missing and needed to reduce memory usage. Just a plan is welcome in the list!
Testing and Benchmarking
(to be written...)
Runtime Bloat Detection
Real-world Data Collection
Memory bloat issues are happening in the real world, but it is hard to reproduce them in our "lab" (tests and buildbots). The efforts are to reproduce real-world memory bloat issues by collecting more real-world memory usage data.
A page that summarizes memory-related information for easier reporting from users for memory bloat. It's similar in concept to about:network-internals. The page can include detailed information (extensions, process status and more) for a specific bloating situation, but less cases (for example than UMA) because it's not automatic. This page should help us get a better understanding of real-world memory issues reports. It might be kicked by observing memory pressure or memory bloat (see MemoryPressureListener).
WANTED: UMA-based tool
While memory-internals is a tool to get detailed information of a specific case, we have had a tool to get rough information from all over the world, UMA. It is however difficult to get correlation between memory usage and something from UMA. For example, "Users using this extension have a tendency to bloat." or like that. We need a tool to find such correlation easily.
"Top-down" means breaking down the entire (or a large part of) memory usage into some parts.
If you set a CHROME_PROFILER_TIME environment variable to 1, the about:profiler page will then show you the amount of memory, in bytes, allocated in each task, listed in the "duration" columns. You can take a couple of snapshots, show the diff and group by process to find out where the memory is going. Note: confirmed to work on Windows by setting a user variable from the system properties panel.
An experimental tool that reports on tcmalloc heap memory usage using the about:tracing TRACE_EVENT macros to generate stacks (instead of real stacks with symbols). Works with release builds without symbols with minimal performance hit, but provides very non-specific stack data. Contact: jamescook@, nduca@
A native (C++-level) memory profiler to breakdown the whole-process memory usage of a long-running process. The goal is to observe and visualize physical memory usage deeper and deeper (e.g. mapped files, mmap and malloc backtraces, C++ object types and more). The limitation is that it works post-mortem and needs a special build (Release with some build options or Debug). It works for Linux and Android for now. Contact: the dmprof group
(to be written...)
memdump (Android only)
Multi-process aware version of /proc/<PID>/smaps.
"Bottom-up" means finding individual specific memory problems like leaks, cyclic reference and else. We have some existing leak finding tools like Massif (in Valgrind
) and heap-checker
LeakSanitizer is an experimental tool that works similarly to Heap Leak Checker. LeakSanitizer is fast and can be used on top of ASan.
WANTED: Tracking reference-counted pointers
Reference-counted pointers can be sources of "hidden" memory leaks as described above. Some good thing to track such "hidden" leaks by reference-counted pointers would help to eliminate memory leaks.
DevTools: for Web-application side
Here you can track number of live DOM Nodes, Documents and JS event listeners in the inspected render process.
Allows to take JS heap snapshots, analyze memory graphs and compare snapshots with each other.
Dynamic version of the JS heap profiler that allows you to see JS object allocation in real time.
Analysis Reports and Case Studies
Let's collect public reports of any kind of memory usage analysis.