Resources | Resources |



Memory fragmentation

Brew MP heap memory for a given process is used to accommodate the following:

  • All the MALLOC() and REALLOC() calls from the process
  • All the ISHELL_CreateInstance() and IEnv_CreateInstance() calls on in-process classes
  • All the MOD and non-shareable MOD1 code for the process

Brew MP applications and the Brew MP system share the same kernel heap for all memory allocations. The heap size is fixed and configured by the manufacturer. As a result, memory fragmentation will become an issue after the device is used for a long period of time.

In typical PC operating systems, when an application starts, it is granted a specific address space by the OS. This address space is virtual, and appears to the application as a single, contiguous block. The OS hides any fragmentation of the physical memory from the application, and no other application may allocate memory from the same virtual address space. So while a PC application can still fragment its own address space, it does not need to worry about fragmentation caused by other applications.

In Brew applications, all addresses are physical, and all applications share the same address space. This means that Brew applications must be mindful of fragmentation issues during execution. When an application starts, the heap may already be fragmented, and the application must be able to gracefully handle it. When an application suspends, it must work to ensure it does not leave the heap in a fragmented state for the next application.

This section covers approaches to help applications manage heap usage, based on the following:

  1. Efficiently using available memory
  2. Ensuring the heap does not become fragmented
  3. Dealing with a heap that has already been fragmented by other applications

For more information on memory allocation, memory nodes, and fragmentation, see the Memory and Heap Technology Guide on the