The objective of the memory manager is generally to allow dynamic memory allocation. For example, in the C programming language, without use of a memory allocation library, memory can only be allocated statically and on the stack, while the use of a memory manager allows for dynamic allocation on the heap. A memory manager can also make allocation and deallocation more efficient, group allocated blocks according to particular conditions, and even collect statistics, and trace memory access violations.
The interface to the memory manager is a set of functions which are used by the program to allocate and release memory. In C, the memory manager is primarily accessed through
free; there are some additional functions, such as
calloc that are closely related to
malloc. In C++ there are 12 global constructs for managing memory:
The DOS community once used the term "memory manager" in a completely different way. A PC "memory manager" was a software system which employed a variety of clever tricks to give applications access to more than 640K of "conventional memory". The best-known examples were Quarterdeck's QEMM product and Microsoft's EMM386.
During the period roughly spanning the mid-1980s through the mid-1990s, PCs were typically limited to 640K of address space for accessing RAM. Software gradually outgrew this constraint as RAM became cheaper. To allow software to use more than 640K, a mechanism called expanded memory appeared. It integrated bank-switching hardware with software support, allowing applications to exploit additional RAM through a window in the address space. The driver servicing the bank-switching hardware was called an Expanded Memory Manager.
Although applications could use expanded memory with relative freedom, many other software components such as drivers and TSRs were still normally constrained to reside within the 640K "conventional memory" area, which soon became a critically scarce resource.
The biggest break-through came with the Intel 80386 processor, its virtual memory support and virtual 8086 mode. This combination allowed to freely model the address space used by real mode programs and a wide variety of software-only approaches were invented to move as much code as possible out of the 640K area.
Memory managers like QEMM might move the bulk of the code for a driver or TSR into extended memory and replace it with a small fingerhold that was capable of accessing the extended-memory-resident code. They might analyze memory usage to detect drivers that required more RAM during startup than they did subsequently, and recover and reuse the memory that was no longer needed after startup. They might even remap areas of memory normally used for memory-mapped I/O. Many of these tricks involved assumptions about the functioning of drivers and other components. In effect, memory managers might reverse-engineer and modify other vendors' code on the fly. As might be expected, such tricks did not always work. Therefore, memory managers also incorporated very elaborate systems of configurable options, and provisions for recovery should a selected option render the PC unbootable (a frequent occurrence).
Installing and configuring a memory manager might involve hours of experimentation with options, repeatedly rebooting the machine, and testing the results. But conventional memory was so valuable that PC owners felt that such time was well-spent if the result was to free up 30K or 40K of conventional memory space.