How Early OSes Managed Scarce Memory: Fixed Partitions, Dynamic Allocation, and Overlays

In the 1960s, system engineers faced extremely expensive memory; a System/360 mainframe offered 256 KB of physical RAM, which was costly and limited. When multitasking was introduced, the core challenge became how to let multiple processes share this scarce resource efficiently.

Fixed Partitioning

The first intuitive solution was to divide physical memory into a few fixed-size partitions, each assigned to a program. A simple C struct illustrates this approach:

struct memory_partition {
    void *start_address; // partition start
    size_t size;         // partition size
    bool is_occupied;   // occupied flag
    int process_id;      // owning process
};

While this allowed several programs to reside in memory simultaneously, it quickly revealed severe waste: a 10 KB program occupied an entire 64 KB partition, and a 70 KB program could not run because no single partition was large enough, even though the total free memory exceeded 70 KB.

Dynamic Partitioning (Variable‑size Allocation)

To improve utilization, memory was allocated on demand. Programs received exactly the amount they needed, tracked via a linked‑list of free blocks:

struct memory_block {
    void *start_address; // block start
    size_t size;         // block size
    bool is_free;        // free flag
    struct memory_block *next; // next block in list
};
struct memory_block *free_list; // head of free list

This method reduced internal fragmentation, but as the system ran longer, external fragmentation accumulated: many small free blocks scattered throughout memory prevented allocation of larger contiguous regions, and programs larger than physical RAM still could not run.

Overlay Technique

Engineers then adopted a manual “overlay” strategy. Large programs were split into a core module that stayed resident and several auxiliary modules that could be loaded into a shared memory region on demand, overwriting previous modules. The process resembled:

void main() {
    // core module always resident
    load_module("module_A", OVERLAY_REGION);
    execute_module_A();
    load_module("module_B", OVERLAY_REGION); // overwrites A
    execute_module_B();
    // reload A when needed again
    load_module("module_A", OVERLAY_REGION);
    execute_module_A_again();
}

Overlays allowed execution of programs larger than physical memory but required programmers to manually partition code and manage loading, leading to complexity, error‑proneness, and performance penalties.

Why Overlays Were Not the Final Answer

Manual memory management is difficult and error‑prone.

Programs must know in advance which modules can share the overlay region.

Frequent loading/unloading degrades performance.

These drawbacks highlighted the need for a system‑level solution that could automatically handle memory, be transparent to programmers, and provide an address space larger than physical RAM—ultimately giving rise to virtual memory.

Overall, the progression from fixed partitions to dynamic allocation and finally to overlays illustrates the early struggles with limited memory and sets the stage for modern operating‑system memory management techniques.