It is important to know how an application is using heap memory, to check for serious memory leaks or excessive allocations and deallocations, which reduce application performance. The Malloc Information view shows the heap memory usage and the volume of allocations and deallocations over time.
The view shows statistical data from the general-purpose, process-level memory allocator:
When you select a process in the Target Navigator view, the IDE queries the target system and retrieves the allocator's statistics. The IDE gathers statistics for the number of bytes that are allocated, in use, or are part of the heap overhead.
This view consists of multiple panes, which are explained in the subsections that follow.
The Total Heap number in the Malloc Information view is an accurate number that the IDE gets from the librcheck.so library; however, the heap size number in the Memory Information view and System Resource view is an estimated number. To get the actual heap size allocated by a process, see the Malloc Information view. To get an overview about what the memory allocation pattern looks like for a process, see the Memory Information view.
The bar chart shows the relative size of each heap.
The Calls Made pane shows the number of times a process has allocated, freed, or reallocated memory by calling malloc, free, and realloc functions. (See the QNX Neutrino C Library Reference.)
The Core Requests pane shows the number of allocations that the system allocator automatically made to accommodate the needs of the program you selected in the Target Navigator view. The system allocator typically dispenses memory in increments of 4 KB (one page).
The number of allocations never equals the number of deallocations, because when the program starts, it allocates memory that isn't released until it terminates.
The History pane shows a chronology of the heap usage shown in the Total Heap pane. The pane automatically rescales as the selected process increases its total heap.
The History pane updates the data every second, with a granularity of 1 KB. Thus, two 512-byte allocations made over several seconds trigger one update.