|
A memory manager is a part of a computer program which accepts requests from the program to allocate and deallocate chunks of memory.
The objectives 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. The 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 malloc and free; there are some additional functions, such as realloc and calloc that are closely related to malloc. In C++ there are 12 global constructs for managing memory: new, new[], delete, delete[], new(nothrow), new(nothrow)[], delete(nothrow), delete(nothrow)[], malloc, calloc, realloc, and free.
PC "Memory Managers" of the LIMS/EMS era
The PC 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 optimize the use of the 640K "conventional memory" area. The best-known example was Quarterdeck's QEMM product.
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, several systems known as LIMS and EMS evolved. These systems integrated bank-switching hardware with software support, allowing applications to exploit more than 640K of RAM.
Although applications could use LIMS/EMS extended RAM 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.
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 manages also incorporated very elaborate systems of configurable options, and provisions for recovery should a selected option render the PC unbootable, as frequently happened.
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.
| 
