Overview
SystemView has the ability to monitor how applications use dynamic storage. This means that if your application uses the C or C++ heap, multiple custom heaps, or memory pool objects offered by an RTOS, you can trace how these are used over time. SystemView can monitor each of these, in the same application, analyze their use, and present the collected information in a way that enables you to see how loaded your heap is, spot potential memory leaks, track peak memory use, and so on.
Heap metrics
SystemView maintains a model of the underlying heap so its state is known at all times. SystemView records every active allocation and deallocation, calculates and records heap loading, and pairs allocation events with deallocation events. In the Heap or Events window, you can move directly back and forth between allocation and matching deallocation events, see the lifetimes of each allocated block of memory in the heap, and monitor the peak and current heap loading to ensure that you have enough heap space for your needs.
User-defined tags
Each block of memory can be tagged; the meaning of the tag is up to the user, but typically the tag identifies the application subsystem that owns that memory block within the heap (for example a transmission layer, a protocol layer, some database, and so on). This tag is maintained in the SystemView application so imposes no additional strain on the target, it simply isn't stored in target memory, aligning with SEGGER's philosophy of minimizing target resource requirements. You can use the tag however you like, filter on it, and monitor the blocks allocated for specific application-defined uses.
Named resources
Heaps and memory blocks can be named, making it easy to identify specific blocks in the SystemView trace. This name is not stored on the target, it is maintained in the SystemView application, and SystemView ensures that any named resources in an API call or in the Resource column of a view show the human-friendly resource name.
Locating memory leaks
A great feature of SystemView's heap monitoring is that it is visually obvious when memory has been allocated but not freed. In many cases this is perfectly fine, long-lived objects can persist for the entire lifetime of the application and never be freed. But if you see the Peak Load of the heap increase over time, you are probably leaking memory, and will eventually run into trouble and most likely crash. Using the Heap monitor, it's easy to see where in the timeline objects are allocated, providing clues to where the leak may be.
Instrumenting your own heaps
Adding instrumentation to your own heap-like objects is a snap! You define the characteristics of the heap once, using SEGGER_SYSVIEW_HeapDefine() and monitor its use with SEGGER_SYSVIEW_HeapAlloc() and SEGGER_SYSVIEW_HeapFree(), which are naturally inserted into heap allocation code.