The Memory Management Reference
Memory management in Mac OS

 Contents | News | Glossary | FAQ | Articles | Bibliography | Links | Feedback

This information is taken from Apple®'s Inside Macintosh: Memory book.

Mac® OS is available on two processor architectures: the Motorola® 68k series and the PowerPCTM.

Mac OS has a flat address space, shared between all processes. There is no per-process memory protection. Application code runs in supervisor mode, so there is no instruction protection. Mac OS has virtual memory(1), in the limited sense that a larger fixed address space can be simulated, by storing the entire address space on disc. This size of this address space is fixed at boot time.

The lowest part of memory is occupied by the system partition. This contains some system global values which applications should not access directly, although there is nothing to prevent them doing so.

Application partitions are allocated from the top of memory downwards; their size is determined by the SIZE resource of the application. At the top of the application is a fixed size data-block known as the "A5 world" (from the name of the register which points to it). On the 68k, this contains the application's static data. Below this, is the stack, growing downwards. The heap grows from the bottom of the application partition upwards and includes code segments.

The meeting point between the stack and the heap is known as ApplLimit. The heap cannot rise above that, but there is no direct protection against the stack extending below it. Instead a "stack sniffer" checks the stack level against ApplLimit up to 60 times a second.

Mac OS supports a form of relocatable heap block, which is accessed indirectly via a handle which points into a master pointer block (a non-relocatable heap block). Heap blocks can optionally be relocatable, and relocatable blocks can be locked. Relocatable blocks are compacted from time to time to avoid external fragmentation. Relocatable blocks can also be marked purgeable, which means the system may free them during compaction if memory becomes low.

It is also possible to allocate "temporary" memory, which is not necessarily contiguous with the application partition. As a guideline, applications should be able to proceed if a temporary allocation fails, and should not keep temporary memory for long. Apple's guidelines on the use of temporary memory are generally felt to be inconsistent with common practice.

Pointers are mainly full 32-bit, but on older systems there were 24-significant-bit pointers, the top 8-bits (of the 32) being used for flags. All systems can be configured to support 24-bit pointers, but at a performance penalty. Applications may be expected to work with both 32-bit and 24-bit pointers; conversion routines are provided.

There are a number of possible problems with external fragmentation: Relocatable blocks cannot be relocated in overlapping memory, so reserving memory for non-relocatable blocks (causing relocatable blocks to move up) can cause gaps to appear in the heap. It is therefore best to allocate non-relocatable blocks first. Locking relocatable blocks can cause the same problems. An application should either allocate relocatable blocks likely to be locked early (just after non-relocatable blocks) or move them to the top of the heap with MoveHHi.

It is important to note that, on the 68k, the Mac OS Memory Manager is inefficient for large numbers of allocations. This is far less of a problem on the Power Macintosh®.