How Memory Allocation Worked in Mac OS 9
Classic Mac OS 9 utilized a static, cooperative memory management model fundamentally different from modern preemptive operating systems. Instead of dynamically assigning memory on demand, Mac OS 9 allocated a fixed, contiguous block of physical RAM—known as an application heap—to each program upon launch. This article explores the architecture of application memory in Mac OS 9, how users manually configured allocations, and the inherent challenges of running software without modern memory protection.
The Static Partition Model
In Mac OS 9, an application could not simply request additional system RAM whenever it needed more space. Instead, each executable had predefined memory parameters stored directly within its file metadata. When a user launched an application, the operating system's Memory Manager searched for an unbroken, contiguous block of free RAM that matched the application's required specifications.
If such a block was found, the OS carved out that memory entirely for the application. The program had to operate strictly within the boundaries of this assigned partition for its entire runtime, housing its executable code, stack, dynamic variables, and application-specific data structures.
The "Get Info" Memory Settings
Because memory allocation was static, users had direct control over how much RAM an application was allowed to use. By selecting an application's icon in the Finder and opening the "Get Info" window (specifically the Memory sub-panel), users were presented with three distinct values:
- Suggested Size: Set by the software developer, this represented the recommended amount of RAM necessary for the application to function reliably under normal conditions. This field was locked and could not be edited by the user.
- Minimum Size: The absolute smallest partition size the application needed to open. If the system did not have enough contiguous RAM to satisfy the Preferred Size, it would attempt to launch using at least this minimum threshold.
- Preferred Size: The user-configurable target allocation. Power users routinely increased this number for memory-heavy applications like Adobe Photoshop or digital audio workstations to prevent out-of-memory errors when working with large files.
Lack of Memory Protection
Mac OS 9 operated in a shared, flat 32-bit address space without hardware-enforced memory protection. While an application was supposed to stay confined to its allocated heap, there were no system-level boundaries preventing a misbehaving program from reading from or writing to memory belonging to another application or even the operating system kernel itself.
A single pointer error, buffer overflow, or unhandled exception within an application would frequently corrupt system memory. This typically resulted in an unrecoverable system freeze, a "Type 11" error, or the infamous Mac OS bomb dialog, requiring a complete hard reboot of the machine.
Memory Fragmentation
Because applications required continuous blocks of memory, the system was heavily prone to RAM fragmentation. If a user opened Application A, Application B, and Application C in sequence, their memory partitions sat side by side in physical RAM.
If the user subsequently quit Application B, the memory it previously occupied became free. However, if the user then attempted to launch a new program that required more memory than the gap left by Application B, the operating system could not launch it—even if the total cumulative amount of free RAM across the system was more than sufficient. Users often had to quit all open applications to consolidate free space.
Virtual Memory and the Code Fragment Manager
Mac OS 9 included a built-in Virtual Memory (VM) implementation, though it functioned differently than modern paging. When VM was enabled in the Memory Control Panel, it created a backing file on the hard drive equal to the total amount of installed RAM plus the additional virtual space.
Enabling Virtual Memory also optimized memory usage through the PowerPC Code Fragment Manager (CFM). Instead of loading an application’s entire code base into the RAM partition at launch, the system mapped the code directly from the disk file and paged it into memory only as needed. This significantly reduced the base RAM footprint of PowerPC applications, allowing more programs to run concurrently within the constraints of the static allocation architecture.