.. _glossary-m: ============================= Memory Management Glossary: M ============================= .. include:: alphabet.txt .. glossary:: machine word .. see:: :term:`word`. main memory .. aka:: *memory*, *primary storage*. The *main memory* (or *primary storage*) of a computer is :term:`memory (1)` that is wired directly to the processor, consisting of :term:`RAM` and possibly :term:`ROM`. These terms are used in contrast to mass storage devices and :term:`cache memory` (although we may note that when a program accesses main memory, it is often actually interacting with a cache). Main memory is the middle level of the :term:`memory hierarchy`: it is slower and cheaper than :term:`caches (1)`, but faster and more expensive than :term:`backing store`. It is common to refer only to the main memory of a computer; for example, "This server has 128 GB of memory" and "macOS High Sierra requires at least 2 GB of memory". .. historical:: Main memory used to be called :term:`core`, and is now likewise often called :term:`RAM`. .. similar:: :term:`core`, :term:`physical memory (1)`, :term:`RAM`. malloc A function in the standard :term:`C` library that performs :term:`dynamic allocation` of :term:`memory (2)`. Many people use "malloc" as a verb to mean "allocate dynamically". .. similar:: :term:`allocate`. .. opposite:: :term:`free (2)`. manual memory management In some systems or languages, it is up to the application program to manage all the bookkeeping details of :term:`allocating ` :term:`memory (2)` from the :term:`heap` and :term:`freeing ` it when no longer required; this is known as manual :term:`memory management`. Manual memory management may be appropriate for small programs, but it does not scale well in general, nor does it encourage modular or object-oriented programming. To quote :ref:`Joyner (1996) `: In C++ the programmer must manually manage storage due to the lack of :term:`garbage collection`. This is the most difficult bookkeeping task C++ programmers face, that leads to two opposite problems: firstly, an object can be :term:`deallocated ` prematurely, while valid :term:`references` still exist (:term:`dangling pointers`); secondly, :term:`dead` objects might not be deallocated, leading to memory filling up with dead objects (:term:`memory leaks`). Attempts to correct either problem can lead to overcompensation and the opposite problem occurring. A correct system is a fine balance. .. historical:: Manual memory management was common in early languages, but :term:`garbage collection` has been around since the late 1950s, in languages like :term:`Lisp`. Most modern languages use :term:`automatic memory management`, and some older languages have :term:`conservative garbage collection` extensions. .. opposite:: :term:`automatic memory management`. .. mps:specific:: Manual memory management can be used with :term:`pools` such as :ref:`pool-mvff` via the functions :c:func:`mps_alloc` and :c:func:`mps_free`. mapped .. aka:: *committed*. A range of :term:`virtual addresses` is said to be *mapped* (*committed* on Windows) if there is :term:`physical memory (2)` associated with the range. Note that, in some circumstances, the :term:`virtual memory` system could actually :term:`overcommit` mapped memory. .. opposite:: :term:`unmapped`. .. seealso:: :term:`mapping`, :term:`memory mapping`, :term:`mmap`. .. mps:specific:: The term *committed* is used. The function :c:func:`mps_arena_committed` returns the total committed memory for an :term:`arena`. mapping A *mapping* is a correspondence between a range of :term:`virtual addresses` and some :term:`memory (1)` (or a :term:`memory-mapped ` object). The physical location of the memory will be managed by the :term:`virtual memory` system. Each :term:`page` in a mapping could be :term:`paged out` or :term:`paged in`, and the locations it occupies in :term:`main memory` and/or :term:`swap space` might change over time. The :term:`virtual address space` can contain of a complex set of mappings. Typically, parts of the address space are :term:`mapped` (have a mapping assigned), others are :term:`reserved` but unmapped, and most of it is entirely :term:`unmapped`. .. figure:: ../diagrams/mapped.svg :align: center :alt: Diagram: Virtual memory with different kinds of mappings. Virtual memory with different kinds of mappings. .. seealso:: :term:`backing store`. mark-compact Mark-compact collection is a kind of :term:`tracing garbage collection` that operates by :term:`marking` :term:`reachable` :term:`objects`, then :term:`compacting ` the marked objects (which must include all the :term:`live` objects). The mark phase follows :term:`reference` chains to mark all reachable objects; the compaction phase typically performs a number of sequential passes over :term:`memory (2)` to move objects and update references. As a result of compaction, all the marked objects are moved into a single contiguous :term:`block` of memory (or a small number of such blocks); the memory left unused after compaction is :term:`recycled`. Mark-compact collection can be regarded as a variation of :term:`mark-sweep collection `, with extra effort spent to eliminate the resulting :term:`fragmentation`. Compaction also allows the use of more efficient :term:`allocation mechanisms`, by making large free blocks available. .. bibref:: :ref:`Edwards `. mark-sweep mark-and-sweep Mark-sweep collection is a kind of :term:`tracing garbage collection` that operates by :term:`marking` :term:`reachable` :term:`objects`, then :term:`sweeping` over :term:`memory (2)` and :term:`recycling ` objects that are unmarked (which must be :term:`unreachable`), putting them on a :term:`free list`. The mark phase follows :term:`reference` chains to mark all reachable objects; the sweep phase performs a sequential (:term:`address`-order) pass over memory to recycle all unmarked objects. A mark-sweep :term:`collector (1)` doesn't move objects. .. historical:: This was the first garbage collection algorithm, devised by John McCarthy for :term:`Lisp`. .. seealso:: :term:`mark-compact`. .. bibref:: :ref:`McCarthy (1960) `. marking Marking is the first phase ("the mark phase") of the :term:`mark-sweep` algorithm or :term:`mark-compact` algorithm. It follows all :term:`references` from a set of :term:`roots` to mark all the :term:`reachable` :term:`objects`. Marking follows :term:`reference` chains and makes some sort of mark for each object it reaches. Marking is often achieved by setting a bit in the object, though any conservative representation of a predicate on the :term:`memory location` of the object can be used. In particular, storing the mark bit within the object can lead to poor :term:`locality of reference` and to poor cache performance, because the marking phases ends up setting the :term:`dirty bit` on all :term:`pages` in the :term:`working set`. An alternative is to store the mark bits separately: see :term:`bitmap marking`. .. seealso:: :term:`compact `, :term:`sweep `. MB .. see:: :term:`megabyte`. megabyte .. aka:: *MB*. A megabyte is 1024 :term:`kilobytes`, or 1048576 :term:`byte (1)`. See :term:`byte (1)` for general information on this and related quantities. memoization .. see:: :term:`caching (3)`. memory (1) .. aka:: *storage*, *store*. *memory* or *storage* (or *store*) is where data and instructions are stored. For example, :term:`caches (1) `, :term:`main memory`, floppy and hard disks are all storage devices. These terms are also used for the capacity of a system to store data, and may be applied to the sum total of all the storage devices attached to a computer. .. historical:: "Store" is old-fashioned, but survives in expressions such as ":term:`backing store`". memory (2) *Memory* refers to :term:`memory (1)` that can be accessed by the processor directly (using memory addressing instructions). This could be :term:`real memory (1)` or :term:`virtual memory`. memory (3) .. see:: :term:`main memory`. memory (4) A :term:`memory location`; for example, "My digital watch has 256 memories." memory bandwidth Memory bandwidth (by analogy with the term *bandwidth* from communication theory) is a measure of how quickly information (expressed in terms of bits) can be transferred between two places in a computer system. Often the term is applied to a measure of how quickly the processor can obtain information from the :term:`main memory` (for example, "My new bus design has a bandwidth of over 400 Megabytes per second"). memory cache .. see:: :term:`cache (1)`. memory hierarchy .. see:: :term:`storage hierarchy`. memory leak .. aka:: *leak*, *space leak*, *space-leak*. A memory leak is where :term:`allocated` :term:`memory (2)` is not :term:`freed (1)` although it is never used again. In :term:`manual memory management`, this usually occurs because :term:`objects` become :term:`unreachable` without being :term:`freed (1)`. In :term:`tracing garbage collection`, this happens when objects are :term:`reachable` but not :term:`live`. In :term:`reference counting`, this happens when objects are :term:`referenced` but not :term:`live`. (Such objects may or may not be :term:`reachable`.) Repeated memory leaks cause the memory usage of a process to grow without bound. memory location .. aka:: *location*. Each separately-:term:`addressable
` unit of :term:`memory (2)` in which data can be stored is called a *memory location*. Usually, these hold a :term:`byte (2)`, but the term can refer to :term:`words`. memory management .. aka:: *storage management*. Memory management is the art and the process of coordinating and controlling the use of :term:`memory (1)` in a computer system. Memory management can be divided into three areas: 1. Memory management hardware (:term:`MMUs`, :term:`RAM`, etc.); 2. Operating system memory management (:term:`virtual memory`, :term:`protection`); 3. Application memory management (:term:`allocation `, :term:`deallocation `, :term:`garbage collection`). Memory management hardware consists of the electronic devices and associated circuitry that store the state of a computer. These devices include RAM, MMUs (memory management units), :term:`cache (1)`, disks, and processor :term:`registers`. The design of memory hardware is critical to the performance of modern computer systems. In fact, :term:`memory bandwidth` is perhaps the main limiting factor on system performance. Operating system memory management is concerned with using the memory management hardware to manage the resources of the :term:`storage hierarchy` and allocating them to the various activities running on a computer. The most significant part of this on many systems is :term:`virtual memory`, which creates the illusion that every process has more memory than is actually available. OS memory management is also concerned with :term:`memory protection` and security, which help to maintain the integrity of the operating system against accidental damage or deliberate attack. It also protects user programs from errors in other programs. Application memory management involves obtaining :term:`memory (2)` from the operating system, and managing its use by an application program. Application programs have dynamically changing storage requirements. The application :term:`memory manager` must cope with this while minimizing the total CPU overhead, interactive pause times, and the total memory used. While the operating system may create the illusion of nearly infinite memory, it is a complex task to manage application memory so that the application can run most efficiently. Ideally, these problems should be solved by tried and tested tools, tuned to a specific application. The Memory Management Reference is mostly concerned with application memory management. .. seealso:: :term:`automatic memory management`, :term:`manual memory management`. Memory Management Unit .. see:: :term:`MMU`. memory manager The memory manager is that part of the system that manages :term:`memory (2)`, servicing :term:`allocation ` requests, and :term:`recycling ` memory, either :term:`manually ` or :term:`automatically `. The memory manager can have a significant effect on the efficiency of the program; it is not unusual for a program to spend 20% of its time managing memory. .. similar:: :term:`allocator`, :term:`collector (1)`. .. seealso:: :term:`memory management`. memory mapping .. aka:: *file mapping*. *Memory mapping* is the technique of making a part of the :term:`address space` appear to contain an "object", such as a file or device, so that ordinary :term:`memory (2)` accesses act on that object. The object is said to be *mapped* to that range of addresses. (The term "object" does not mean a program :term:`object`. It comes from Unix terminology on the :term:`mmap` man page.) .. figure:: ../diagrams/mapping.svg :align: center :alt: Diagram: An address space with a range mapped to part of an object. An address space with a range mapped to part of an object. Memory mapping uses the same mechanism as :term:`virtual memory` to "trap" accesses to parts of the :term:`address space`, so that data from the file or device can be :term:`paged in` (and other parts :term:`paged out`) before the access is completed. .. historical:: File mapping is available on most modern Unix and Windows systems. However, it has a much longer history. In Multics, it was the primary way of accessing files. .. seealso:: :term:`mapped`. memory protection .. see:: :term:`protection`. message .. mps:specific:: A data structure which the MPS uses to communicate with the :term:`client program`. See :ref:`topic-message`. message queue .. mps:specific:: A queue of :term:`messages` posted by an :term:`arena`. It can be queried by calling :c:func:`mps_message_poll`, :c:func:`mps_message_queue_type`, or :c:func:`mps_message_get`. See :ref:`topic-message`. message type .. mps:specific:: A value of type :c:type:`mps_message_type_t` describing the type of a :term:`message`. There are three message types: :c:func:`mps_message_type_finalization`, :c:func:`mps_message_type_gc`, and :c:func:`mps_message_type_gc_start`. See :ref:`topic-message`. misaligned .. see:: :term:`unaligned`. miss A miss is a lookup failure in any form of :term:`cache (3) `, most commonly at some level of a :term:`storage hierarchy`, such as a :term:`cache (1)` or :term:`virtual memory` system. The cost of a miss in a virtual memory system is considerable: it may be five orders of magnitude more costly than a hit. In some systems, such as multi-process operating systems, other work may be done while a miss is serviced. .. opposite:: :term:`hit`. .. seealso:: :term:`miss rate`. miss rate At any level of a :term:`storage hierarchy`, the miss rate is the proportion of accesses which :term:`miss`. Because misses are very costly, each level is designed to minimize the miss rate. For instance, in :term:`caches (1)`, miss rates of about 0.01 may be acceptable, whereas in :term:`virtual memory` systems, acceptable miss rates are much lower (say 0.00005). If a system has a miss rate which is too high, it will spend most of its time servicing the misses, and is said to :term:`thrash`. Miss rates may also be given as a number of misses per unit time, or per instruction. .. opposite:: :term:`hit rate`. mmap ``mmap`` is a system call provided on many Unix systems to create a :term:`mapping` for a range of :term:`virtual addresses`. MMU .. aka:: *Memory Management Unit*. The MMU (Memory Management Unit) is a hardware device responsible for handling :term:`memory (2)` accesses requested by the main processor. This typically involves translation of :term:`virtual addresses` to :term:`physical addresses`, :term:`cache (1)` control, bus arbitration, :term:`memory protection`, and the generation of various exceptions. Not all processors have an MMU. .. seealso:: :term:`page fault`, :term:`segmentation violation`, :term:`virtual memory`. mostly-copying garbage collection A type of :term:`semi-conservative ` :term:`tracing garbage collection` which permits :term:`objects` to :term:`move ` if no :term:`ambiguous references` point to them. The techniques used are a hybrid of :term:`copying garbage collection` and :term:`mark-sweep`. Mostly-copying garbage collectors share many of the benefits of copying collectors, including :term:`compaction`. Since they support ambiguous references they are additionally suitable for use with uncooperative compilers, and may be an efficient choice for multi-threaded systems. .. bibref:: :ref:`Bartlett (1989) `, :ref:`Yip (1991) `. .. mps:specific:: The :ref:`pool-amc` pool class implements mostly-copying garbage collection. mostly-exact garbage collection .. see:: :term:`semi-conservative garbage collection`. mostly-precise garbage collection .. see:: :term:`semi-conservative garbage collection`. moving garbage collector moving memory manager A memory manager (often a :term:`garbage collector`) is said to be *moving* if :term:`allocated` :term:`objects` can move during their lifetimes. .. relevance:: In the garbage collecting world this will apply to :term:`copying ` collectors and to :term:`mark-compact` collectors. It may also refer to :term:`replicating ` collectors. .. similar:: :term:`copying garbage collection`. .. opposite:: :term:`non-moving garbage collector`. mutable Any :term:`object` which may be changed by a program is *mutable*. .. opposite:: :term:`immutable`. mutator .. aka:: *client program*. In a :term:`garbage-collected ` system, the part that executes the user code, which :term:`allocates` :term:`objects` and modifies, or *mutates*, them. For purposes of describing :term:`incremental garbage collection`, the system is divided into the *mutator* and the :term:`collector (2)`. These can be separate threads of computation, or interleaved within the same thread. The user code issues allocation requests, but the allocator code is usually considered part of the collector. Indeed, one of the major ways of scheduling the other work of the collector is to perform a little of it at every allocation. While the mutator mutates, it implicitly :term:`frees ` :term:`memory (1)` by overwriting :term:`references`. .. historical:: This term is due to :ref:`Dijkstra et al. (1976) `. .. opposite:: :term:`collector (2)`. .. mps:specific:: The MPS documentation uses the term :term:`client program` to refer to the mutator.