MemoryProfiler
This page describes the idea of a profiler that focuses on the memory footprints of execution flows.
Objectives
Traditional memory analysis tools look at the data. They build the referring-to, namely retaining graphs. This is helpful in exploring the relationships among objects and identifying memory leaks. However, the information exposed in this way is usually a snapshot and the history of how memory is used is missing. Moreover, they usually don't keep tracks of how objects are allocated. Developers have to infer how an object might be allocated and freed by himself/herself.
Another common approach is to plot the allocations or the memory usages along the timeline. This gives some intuition of how and when a bulk of objects are allocated. However, it still relies on developers' wisdom, and sometimes chances, to dig out the problematical code snippet.
This memory profiler is designed to solve the inconveniences and limitations. The goal is to identify the memory eager codes directly. For example, it can show which functions retaining most:
SelfSize TotalSize Name
4653056 9502720 p/this.start (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
1310720 2097152 a (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
1245184 1245184 nsJSContext::GarbageCollectNow
1179648 1179648 PresShell::DoReflow
983040 983040 nsCycleCollector::collectSlice
983040 983040 IPDL::PHttpChannel::RecvOnTransportAndData
851968 851968 t/t.prototype._create (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:12)
or having highest peaks:
SelfHWM TotalHWM Name
6225920 17563648 p/this.start (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
6029312 6029312 s (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
4784128 4849664 nsDisplayBoxShadowOuter::Paint
1966080 1966080 IPDL::PHttpChannel::RecvOnTransportAndData
1769472 6684672 a (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:11)
1572864 18153472 u (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
1572864 1572864 nsJSContext::GarbageCollectNow
1507328 1507328 PresShell::DoReflow
1507328 13500416 p/<.run/x/< (https://marketplace.cdn.mozilla.net/media/fireplace/js/include.js?b=1412710964149:8)
The Design
The memory profiler samples allocation events. An allocation event includes a type (what and at where is going to be allocated), a size, a timestamp and the corresponding stack trace. Free events are also tracked. For managed languages, namely languages relying on garbage collection, a free event is generated when an object is reclaimed by the garbage collector.
These sampled events can be used to approximate the full history of allocations afterwards. That means we can get various memory profiles of a program in different perspectives by post-processing the history in different ways.
The profiler is designed at the very beginning to support not only JavaScript but also native codes. Naturally, not only JavaScript objects but also native allocations are tracked.
Applications
Besides the two examples showing the functions retaining most and having highest peak, it can be used to find out functions, code snippets or call paths allocating most.
In addition to the ranking list, a call-tree can also be rendered.
With the help of the timestamp, a size-time map can be plotted, too.
Features
The profiler is composed of two parts: the sampling engine and the front-end. Currently most of the efforts are devoted to the back-end and only a few JavaScript examples (quite useful but less convenient than you would expect) is available to give access to the profiler.
The profiler will be able to
- Provide a way to start/stop
- A timeline that:
- shows the overall memory usage history
- allows zooming into a time interval for the following views
- A rank-list view that shows top functions that are most memory eager
- 6 measurements: {retained, allocated, peak} x {self, inclusive}
- A tree view that shows functions as call trees
- 6 measurements: {retained, allocated, peak} x {self, inclusive}
- A filter to focus on interested functions
User Interface
