Heap monitoring

Each block of memory can be tagged, with the meaning of the tag left to the user's discretion. Typically, the tag identifies the embedded application subsystem that owns the memory block within the heap (for example, a transmission layer, a protocol layer, or a database). This tag is maintained in the SystemView application, so it imposes no additional strain on the target. It is simply not stored in the target memory, aligning with SEGGER's philosophy of minimizing resource requirements on the target embedded system. You can use the tag as needed, filter based on it, and monitor blocks allocated for specific, application-defined purposes.

Heaps and memory blocks can be given names, making it easier to identify specific blocks in the SystemView trace. These names are not stored on the target; instead, they are maintained within the SystemView application. SystemView ensures that any named resources in an API call or in the Resource column of a view display the human-friendly resource name.

SystemView's memory heap monitoring makes it visually obvious when memory has been allocated but not freed. In many cases, this is perfectly acceptable—long-lived objects can persist for the entire lifetime of an application without needing to be freed. However, if you notice the peak load of the heap increasing over time, you are likely experiencing a memory leak, which can eventually cause problems and lead to a crash. With the heap monitor, it’s easy to track when objects are allocated along the timeline, providing useful clues as to where the leak may be occurring.

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.