Process memory

Typically, virtual memory occupied by a process can be separated into the following categories:

  • Code — Contains the executable code for a process and the code for the shared libraries. If more than one process uses the same library, then the virtual segment containing its code is mapped to the same physical segment (that is, shared between processes).
  • Data — Contains a process data segment and the data segments for the shared libraries. This type of memory is referred to as static memory.
  • Stack — This segment contains memory required for function stacks (one stack for each thread).
  • Heap — This segment contains all memory dynamically allocated by a process.
  • Shared Heap — Contains other types of memory allocation, such as shared memory and mapped memory for a process.

It is important to know how much memory each individual process uses, otherwise you can spend considerable time trying to optimize the heap (that is, if a process uses only 5% of the total process memory, is it unlikely to return any noticeable result). Techniques for optimizing a particular type of memory are also dramatically different.

For information about obtaining process memory distribution details, see Inspect your process memory distribution.

The main system allocator has been instrumented to track statistics associated with allocating and freeing memory. This lets the memory statistics module unobtrusively inspect any process's memory usage.

When you launch your program with the Memory Analysis tool, your program uses the debug version of the malloc library ( Besides the normal statistics, this library also tracks the history of every allocation and deallocation, and provides cover functions for the string and memory functions (for example, strcmp, memcpy, memmove). Each cover function validates the corresponding function's arguments before using them. For example, if you allocate 16 bytes, then forget the terminating NULL character and attempt to copy a 16-byte string into the block using the strcpy function, the library detects the error.

The debug version of the malloc library uses more memory than the nondebug version. When tracing all calls to malloc, the library requires additional CPU overhead to process and store the memory-trace events.

Be sure to occasionally check the Downloads area on our website for updated versions of the debug malloc library.

The QNX Memory Analysis perspective can help you pinpoint and solve various kinds of problems, including:

Inspect your process memory distribution

It is important to know how much memory each individual process uses, otherwise you can spend considerable time trying to optimize the heap. Therefore, you can use the System Information view to inspect the distribution and overall memory usage for each process.

In order to complete this task, the Momentics IDE for BlackBerry must be currently running, you must have created a target project, and your target host must be connected.

To inspect the process memory distribution:
  1. Run the process that you want to inspect on the target.
  2. Switch to the System Information perspective.
  3. In the Target Navigator view, select the target on which your process is running.
  4. Switch to the System Summary view.
    In this view, you can obtain an overview of the process memory.
  5. On the All Processes tab, select a process.

    System Summary view

    From this illustration, you can see how much physical memory the selected process occupies; in this example, it is 116 KB of Code, and 292 KB of Data.

  6. Switch to the Memory Information view.
  7. In the Target Navigator view, expand your target and select the same process you selected earlier.

    You can see a detailed map of the virtual memory for the process.

Based on the memory distribution information in the preceding example, you can determine if it is ideal to allocate time to optimize the heap memory. If not, you might want to consider optimizing something else, such as the stack or static memory.

Last modified: 2015-03-31

Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus