Resources | Resources |



High-level Architecture

In the architecture of Brew MP, heap and heap-related interfaces are part of the System family, as shown in the following figure:

In Brew MP, there are two types of heap memory:

  • Kernel heap - Used by the Brew MP kernel. Brew and applications that run in the Brew process use kernel heap.
  • Page heap - Used by Brew MP for loading dynamic modules from the file system.

In a Brew MP system, each process has its own default heap from which memory allocations are drawn. This default heap is created at the time the process is created and can grow up to the size specified in the maxmemory argument of the Program or Server primitive from the MIF file that declares the process. The memory drawn to create this heap is provided by the underlying kernel, which manages the available physical memory on the device.

In Brew, the heap for the kernel process is a special heap known as the kernel process heap or kernel heap. Unlike user heaps, which may start off small and grow until a maximum limit is reached, the kernel heap is declared as a static array of bytes of fixed size, configured by the manufacturer and compiled as part of the device build. The kernel heap is the default heap for any Brew software executing in the kernel process.

As a measure aimed at reducing fragmentation of the kernel heap, Brew allows manufacturers to configure the kernel heap to operate as a split heap. When configured as a split heap, the kernel heap is partitioned such that all small (4KB or less) allocations are drawn from the small kernel heap partition and all large allocations (larger than 4KB) are drawn from the large kernel heap. Configuring the heap in this manner may help to confine most heap fragmentation to the small kernel heap partition, helping to keep small allocations from littering the heap in such a way as to prevent a large contiguous allocation from succeeding.

For information on configuring kernel heap and page heap, see Configuring heap size.

Allocating heap

For an application or service running in its own process, Brew MP allocates and manages the heap per process. In this case, heap memory is allocated from the page heap. The process-heap can grow dynamically, up to a limit configured for each process. This is an advantage over memory models that share heap among applications, where corruption or exhaustion of the shared heap can destabilize other running applications.

For applications running in the Brew process, applications can allocate memory from the kernel heap, which is managed per application context.

Brew MP allocates kernel heap as prescribed by k1kheap.c, an implementation model which device manufacturers can configure to suit their hardware. While the reference code delivered in k1kheap.c changed a great deal between BREW 3.1.5 and BREW 4.0, memory management in Brew MP, especially at the application-level, has not changed since then. Thus, backward compatibility has been preserved.

Brew MP keeps track of memory allocated by applications to prevent memory leaks. It maintains an information block called a heap node for each chunk of memory allocated from the heap. By default, Brew MP tags the allocated memory’s heap node with the 32-bit module context ID for the calling application.