.. _glossary-r: ============================= Memory Management Glossary: R ============================= .. include:: alphabet.txt .. glossary:: RAM .. aka:: *random access memory*. RAM (random access memory) is a type of :term:`physical memory (2)` that can be read from and written to. .. similar:: :term:`main memory`. .. seealso:: :term:`ROM`, :term:`static RAM`, :term:`dynamic RAM`. random access memory .. see:: :term:`RAM`. ramp allocation .. mps:specific:: An :term:`allocation pattern` indicating to the MPS that most of the blocks allocated after the call to :c:func:`mps_ap_alloc_pattern_begin` are likely to be :term:`dead` by the time of the corresponding call to :c:func:`mps_ap_alloc_pattern_end`. See :ref:`topic-pattern-ramp`. rank .. mps:specific:: A value of :c:type:`mps_rank_t` indicating whether a :term:`root` is :term:`ambiguous ` (:c:func:`mps_rank_ambig`), :term:`exact ` (:c:func:`mps_rank_exact`) or :term:`weak ` (:c:func:`mps_rank_weak`). rash .. mps:specific:: A :term:`variety` in which no MPS functions :term:`assert ` that their data structures are valid. Select it by defining :c:macro:`CONFIG_VAR_RASH`. Compare :term:`cool` and :term:`hot`. raw .. see:: :term:`unwrapped`. reachable An :term:`object` is *reachable* if it is :term:`referred ` to by a :term:`root`, or is referred to by a reachable object; that is, if it can be reached from the roots by following :term:`references`. Reachability is used as an approximation to :term:`liveness ` in :term:`tracing garbage collection`. In :term:`Java`, the :term:`reference objects` together with ordinary references and :term:`finalization` generate a hierarchy of reachability that guides the :term:`collector (1)` on what to do when an object is about to :term:`die `. There are six strengths: 1. :term:`strongly reachable`; 2. :term:`softly reachable`; 3. :term:`weakly reachable`; 4. :term:`finalizable `; 5. :term:`phantom reachable`; 6. :term:`unreachable`. Basically, an object is only as reachable as the weakest link in the strongest path from the roots. Note that the Java specification's description of the reachabilities is a bit patchy, but that's what it intends. It is unspecified where Java Native Interface's *weak global references* fit into this. .. similar:: :term:`live`. .. opposite:: :term:`unreachable`. .. link:: `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. read barrier A read :term:`barrier (1)` is a block on reading from certain :term:`memory (2)` :term:`locations ` by certain threads or processes. .. relevance:: Read barriers are used for :term:`incremental ` or :term:`concurrent ` :term:`garbage collection`. .. seealso:: :term:`write barrier`. read fault An exception which occurs when reading from an address in :term:`virtual memory`. This is probably either a :term:`page fault`, an :term:`invalid page fault` or a :term:`protection fault`. .. similar:: :term:`segmentation violation`. .. seealso:: :term:`write fault`. read-only memory .. see:: :term:`ROM`. real memory (1) A system with no :term:`virtual memory` capability can be said to have *real memory*. .. historical:: On older architectures, programs could only directly access data in real memory. Where this was inefficient, they had to store data on disk, and sometimes had alternate portions of program image called *overlays*. .. opposite:: :term:`virtual memory`. real memory (2) .. see:: :term:`physical memory (1)`. reclaim *Reclaiming* an :term:`object` or the :term:`memory (1)` occupied by it is making it available for reuse after the object is no longer needed. This word is usually used only in connection with :term:`automatic memory management`. .. similar:: :term:`recycle`. recycle *Recycling* :term:`memory (1)` means making it available for reuse after it has been occupied by an :term:`object` that is no longer needed. In simple cases, this might simply involve adding a :term:`memory (2)` :term:`block` to the :term:`free list`. Another possibility is :term:`unmapping ` memory so that the :term:`backing store` can be allocated to another process. .. similar:: :term:`reclaim`. reference In memory management, *a reference* is the general term for a link from one :term:`object` to another. Some programming languages have more specific meanings for the term. The terms ":term:`pointer`" and "reference" are often interchangeable, but some programming languages differentiate the two in subtle ways. .. similar:: :term:`address`, :term:`pointer`. .. mps:specific:: A reference is represented in the :term:`C` interface by a value of type :c:type:`mps_addr_t` (an alias for ``void *``) which points to a :term:`memory location` within the object (typically the base of the object, but for objects with :term:`headers ` this may not be the case). The pointer returned by :c:func:`mps_alloc` and :c:func:`mps_reserve` is a reference to the object allocated. The :term:`client program` is free to represent references as it chooses (for example, with :term:`tags `), provided that during :term:`scanning ` it is able to decode a reference from its representation into the MPS interface representation and encode a reference from the MPS into its representation. reference counting Reference counting systems perform :term:`automatic memory management` by keeping a count in each :term:`object`, usually in a :term:`header `, of how many :term:`references` there are to the object. Objects to which there are no references cannot be accessed by the :term:`mutator`; they are therefore :term:`dead` and may be :term:`reclaimed `. The reference count is incremented for each new reference, and is decremented if a reference is overwritten, or if the referring object is recycled. If a reference count falls to zero, then the object is no longer required and can be recycled. There are four main problems with simple reference counting: 1. The reference count field usually has to have limited size, and the system therefore breaks down if the number of possible references to an object is unbounded; 2. Reference counting involves an operation on every modification of a pointer, which increases code size, increases demand for :term:`memory bandwidth`, decreases :term:`locality of reference` and can be a serious performance penalty (especially in multi-threaded environments where reference count updates require synchronization); 3. Every object needs to be slightly larger in order to store the reference count; 4. If any objects are part of a :term:`cyclic data structure` then they will always have a non-zero reference count, and hence won't be reclaimed when they are dead. .. figure:: ../diagrams/refloop.svg :align: center :alt: Diagram: Garbage with non-zero reference counts. Garbage with non-zero reference counts. Reference counting has the advantage that it can reclaim objects promptly, and for this reason it is often used to reclaim non-cyclic data structures in file systems, databases and operating system kernels. When there is a possibility of cyclic data structures, reference counting is sometimes used together with a :term:`tracing garbage collector ` that runs infrequently. Such combinations are generally less efficient than using a tracing collector by itself, but the promptness of reference counting may be important. Pauses due to reference counting are typically fairly short, and it may be appropriate as a form of :term:`incremental garbage collection`. But removing a single reference may cause the recycling of a large number of objects at once, so it is not suited to real-time systems where minimum pause times must be guaranteed. There are more complex variations of the technique that address this problem. Reference counting is often used because it can be implemented without any support from the language or compiler. In :term:`C++` this can be encapsulated in a class, using a :term:`smart pointer`. However, it would normally be more efficient to use a tracing garbage collector instead. The performance of reference counting can be improved substantially with compiler support, using refinements such as :term:`deferred reference counting`, which has been successfully used in :term:`Smalltalk` and other languages. Despite the problems, reference counting is often used for :term:`distributed garbage collection`. This is because refinements such as :term:`weighted reference counting` require less inter-process communication than :term:`tracing `. .. seealso:: :term:`limited-field reference count`, :term:`one-bit reference count`. reference object In :term:`Java`, a *reference object* (``java.lang.ref.Reference``) encapsulates a :term:`reference` to some other object, in order to make the :term:`garbage collector` handle it specially. In particular, a Java program can use this to detect when the referent becomes :term:`unreachable`. Basically, the encapsulated reference is a :term:`weak reference (1)`; it will be cleared by the :term:`collector (1)` when all other references to the referent have disappeared. However, in order to better control what happens at the end of an object's :term:`lifetime`, Java 1.2 provides three classes of reference objects, each with its own peculiarities: ``SoftReference``, ``WeakReference``, and ``PhantomReference``. Each of these classes has its uses in managing memory. The reference objects together with ordinary references and :term:`finalization` generate a hierarchy of :term:`reachability ` that guides the collector on what to do when an object is about to :term:`die `. A reference object can be *registered* with a queue, and it will be enqueued when the collector determines that the referent is :term:`softly `, :term:`weakly ` or :term:`phantom reachable`, as the case may be. A program can use these queues to perform some action when an object is dying. This allows finer control than the older :term:`finalization` mechanism alone. .. historical:: This feature was introduced in Java 1.2 (confusingly, part of the Java 2 Platform). .. seealso:: :term:`soft reference`, :term:`weak reference (2)`, :term:`phantom reference`. .. link:: `Package java.lang.ref `_, `Reference Objects and Garbage Collection `_. .. bibref:: :ref:`Dybvig et al. (1993) `. region inference Region inference is a technique for determining when :term:`objects` become :term:`dead` (even if they are :term:`reachable`) by a static analysis of the program. Region inference infers a *region* for each object. When a region dies, all the objects in it are known to be :term:`dead`, whether reachable or not. Regions obey a strict :term:`stack` discipline; that is, when a region dies, all younger regions also die. In this way, region inference occupies a middle ground between :term:`stack allocation` and :term:`heap allocation`. .. bibref:: :ref:`Tofte & Talpin (1997) `. register A *register* is a small unit of :term:`memory (2)` that is attached to a processor and accessible very quickly. Registers typically form the highest level of a computer's :term:`storage hierarchy`. .. relevance:: In some programs (for example, those compiled by typical :term:`C` or :term:`C++` compilers), a subset of the registers is always accessible by the :term:`mutator` and so forms a :term:`root`. .. mps:specific:: The :term:`scan method` for the root containing the registers is hard to write (it depends on the operating system, the processor architecture, and in some cases the compiler), so the MPS provides (on its supported platforms) the function :c:func:`mps_stack_scan_ambig`. register set partitioning Run-time systems for :term:`garbage-collected ` languages sometimes partition the set of machine :term:`registers` *a priori* into two categories: those always :term:`traced ` and updated by the :term:`garbage collector` and those ignored by it. The former are always maintained in a format understood by the collector; the latter are never used to hold :term:`references` to collectable :term:`objects`. More complicated schemes are also possible. This partitioning provides a separation of concerns between the compiler and the :term:`garbage collector`. The compiler can generate code that produces values the garbage collector would not be able to handle (say, because they have no :term:`tags`), as long as those values are kept in the ignored registers. The garbage collector can trust that the registers it looks at always contain valid data, and can perform :term:`exact garbage collection`. Register set partitioning increases the demand for registers (*register pressure*), but may reduce the amount of :term:`boxing ` needed. relocation *Relocating* means moving data from one location to another and updating all :term:`references`. Relocation is often performed to avoid :term:`external fragmentation`. Program loading sometimes relocates code and :term:`static ` data. .. similar:: :term:`moving `. .. seealso:: :term:`compaction`, :term:`moving memory manager`. remembered set A remembered set is the technique of keeping a separate list of interesting :term:`references` between two sets of :term:`objects`, so you don't have to find them by :term:`scanning `. Many :term:`memory management` algorithms depend on partitioning the objects and require special handling for references between partitions. Keeping track of such references in a remembered set eliminates the need to scan the originating partition to find them. A typical use in :term:`generational garbage collection` is remembering :term:`references` from an older :term:`generation` to a younger one. .. similar:: :term:`entry table (2)`. .. bibref:: :ref:`Ungar (1984) `, :ref:`Jones et al. (2012) `. remote reference .. mps:specific:: A :term:`reference` that logically belongs to a :term:`formatted object` and so must be :term:`fixed` when the object is :term:`scanned `, but which is not stored within the block containing the object. (For example, in an auxiliary table of some sort.) The MPS does not generally support remote references because those references may be :term:`protected ` and so if :term:`scan method` attempts to :term:`fix` them this will hit a :term:`barrier (1)` and cause a re-entrant call to the MPS. replicating garbage collector A variant of :term:`copying garbage collection`, which does not destroy the original :term:`object` when making a copy. This is useful in an :term:`incremental ` or :term:`concurrent ` :term:`collector (1)`, as no :term:`read barrier` is required; the :term:`mutator` can continue to use old objects. The collector uses a :term:`write barrier` to replicate the writes to the new copies. .. seealso:: :term:`copying garbage collection`, :term:`broken heart`. .. bibref:: :ref:`Nettles et al. (1992) `, :ref:`Nettles & O'Toole (1993) `, :ref:`Nettles & O'Toole (1993a) `, :ref:`O'Toole & Nettles (1994) `. reserved In a :term:`virtual memory` system, it is usually possible to hold range of :term:`virtual addresses` *reserved* without making it :term:`mapped`. Reserving addresses prevents other components of the program using the same addresses, without consuming :term:`swap space`. This technique is often used in :term:`BIBOP` schemes, where one might want to reserve a large amount of :term:`address space` but only sparsely map it. On some systems there are special calls for reserving; on others one can create :term:`mappings` that don't need :term:`backing store`. For example, on some Unix systems, ``mmap /dev/zero`` with no access. .. seealso:: :term:`mapping`, :term:`mmap`. resident In a :term:`cache (2)` system, that part of the cached storage which currently has a copy in the cache is called *resident*. Ideally, the :term:`working set` should be resident. .. seealso:: :term:`cache (2)`, :term:`storage hierarchy`, :term:`resident set`. resident set In a :term:`virtual memory` system, a process' resident set is that part of a process' :term:`address space` which is currently in :term:`main memory`. If this does not include all of the process' :term:`working set`, the system may :term:`thrash`. result code .. mps:specific:: A value returned from an MPS function, represented by the type :c:type:`mps_res_t`. The result code :c:macro:`MPS_RES_OK` indicates success; other values indicate errors. See :ref:`topic-error`. resurrection An object is said to have been *resurrected* if it was determined to be :term:`finalizable ` by the :term:`garbage collector` (that is, the only thing keeping it alive was the fact that it required finalization), but then a new :term:`strong reference` was created to it. This can happen via a :term:`weak reference (1)` or by the finalization procedure storing a permanent copy of its reference to the object. .. mps:specific:: See :ref:`topic-finalization`. ROM .. aka:: *read-only memory*. ROM (read-only memory) is a type of :term:`physical memory (2)` that can be read from, but not written to. The contents of ROM are usually set in the factory. .. seealso:: :term:`RAM`. root In :term:`tracing garbage collection`, a root holds a :term:`reference` or set of references to :term:`objects` that are *a priori* :term:`reachable`. The :term:`root set` is used as the starting point in determining all reachable data. Roots basically comprise the references in the state of the :term:`mutator`. Typical roots are global variables, other :term:`static ` data, and the :term:`control stack`. .. seealso:: :term:`weak root`, :term:`strong root`, :term:`ambiguous root`, :term:`exact root`. .. mps:specific:: See :ref:`topic-root`. root description .. mps:specific:: The :term:`arena` uses root descriptions to find :term:`references` within the :term:`client program's ` :term:`roots`. Root descriptions belong to the type :c:type:`mps_root_t`. root mode .. mps:specific:: A value of type :c:type:`mps_rm_t` describing whether a :term:`root` is :term:`constant `, :term:`protectable `, or both. The root mode tells the MPS whether it may place a :term:`barrier (1)` on the root. root set The *root set* is the collection of :term:`roots` that the :term:`mutator` declares to the :term:`collector (2)`. .. seealso:: :term:`garbage collection`.