Mac OS 9 Virtual Memory Mechanisms Explained
This article examines how the classic Mac OS 9 operating system implemented virtual memory, detailing its paging architecture, the structure of its backing store on the hard drive, and the techniques used to manage data movement between physical RAM and disk storage. While modern operating systems feature fully isolated, preemptive virtual memory architectures, Mac OS 9 used a specialized implementation tailored to its cooperative multitasking model and PowerPC hardware.
The Backing Store: The VM Storage File
Mac OS 9 handled data swapping to the hard drive using a contiguous,
hidden file located at the root level of the boot volume (or an
alternate designated drive) named VM Storage. Unlike modern
systems that expand and shrink swap space dynamically as system demand
fluctuates, Mac OS 9 required the backing store to be configured ahead
of time via the Memory Control Panel.
When virtual memory was enabled, the VM Storage file was
allocated as a static block during startup. The total size of this file
was not simply the amount of virtual memory added; it was equal to the
total size of physical RAM plus the additional virtual address space
requested. For example, a system with 128 MB of RAM set to use 192 MB of
virtual memory created a 192 MB VM Storage file to ensure a
full 1:1 backing map for every potential page.
4 KB Paging and MMU Integration
Mac OS 9 leveraged the hardware Memory Management Unit (MMU) of PowerPC processors (PowerPC 603, 604, G3, and G4) to divide address space into uniform 4-kilobyte (4 KB) pages.
The Virtual Memory Manager tracked whether a required page of memory resided in physical RAM or on the disk:
- Page Faults: When a running program attempted to access an address not currently mapped to physical RAM, the MMU triggered an exception known as a page fault.
- Interrupt Handling: The Mac OS 9 Virtual Memory
Manager intercepted this interrupt, paused the thread, located the
corresponding 4 KB block in the
VM Storagefile, and read it into an available frame in physical RAM. - Replacement Strategy: To make room for incoming pages, the operating system utilized a modified Least Recently Used (LRU) page-replacement algorithm.
Clean Pages vs. Dirty Pages
To minimize slow disk write cycles, Mac OS 9 distinguished between "clean" and "dirty" memory pages:
- Read-Only Code (File Mapping): PowerPC-native
applications used file mapping directly from the application's
executable file on disk. Executable code pages were treated as
read-only. When the system needed to discard a code page from RAM, it
did not write it to the
VM Storagefile; it simply freed the RAM frame. If needed again later, the page was re-read directly from the original application binary. - Writable Data: Application heaps, stacks, and
modified variables were marked as dirty. When one of these pages was
chosen for eviction, the Virtual Memory Manager wrote the modified 4 KB
block to the
VM Storagefile before releasing the RAM frame.
Architectural Limits in the Classic Architecture
Because Mac OS 9 lacked a fully preemptive kernel and per-process memory protection, its virtual memory operated across a single, shared 32-bit address space. This introduced specific behaviors:
- Hold and Lock Mechanisms: Time-critical code, such
as interrupt service routines, sound processing, and device drivers,
could not tolerate the latency of a disk page fault. Developers used
system calls like
HoldMemoryorLockMemoryContiguousto pin critical pages into physical RAM, preventing the Virtual Memory Manager from paging them out to disk. - Disk Thrashing: If the available physical RAM was low relative to active working sets, frequent page swapping led to audible and visible disk thrashing, as cooperative tasks were forced to wait synchronously on disk I/O before continuing execution.