1
Fork 0
mirror of git://git.sv.gnu.org/emacs.git synced 2026-01-18 00:50:44 -08:00
emacs/mps/manual/html/glossary/i.html
Gareth Rees 06057a4d52 Bring html up to date.
Copied from Perforce
 Change: 181168
 ServerID: perforce.ravenbrook.com
2013-03-18 15:13:54 +00:00

512 lines
No EOL
38 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Memory Management Glossary: I &mdash; Memory Pool System 1.111.0 documentation</title>
<link rel="stylesheet" href="../_static/mps.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.111.0',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="copyright" title="Copyright" href="../copyright.html" />
<link rel="top" title="Memory Pool System 1.111.0 documentation" href="../index.html" />
<link rel="up" title="Memory Management Glossary" href="index.html" />
<link rel="next" title="Memory Management Glossary: K" href="k.html" />
<link rel="prev" title="Memory Management Glossary: H" href="h.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="k.html" title="Memory Management Glossary: K"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="h.html" title="Memory Management Glossary: H"
accesskey="P">previous</a> |</li>
<li><a href="../index.html">Memory Pool System 1.111.0 documentation</a> &raquo;</li>
<li><a href="index.html" accesskey="U">Memory Management Glossary</a> &raquo;</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="memory-management-glossary-i">
<span id="glossary-i"></span><h1>Memory Management Glossary: I<a class="headerlink" href="#memory-management-glossary-i" title="Permalink to this headline"></a></h1>
<p class="glossary-alphabet"><a class="reference internal" href="a.html#glossary-a"><em>A</em></a>
| <a class="reference internal" href="b.html#glossary-b"><em>B</em></a>
| <a class="reference internal" href="c.html#glossary-c"><em>C</em></a>
| <a class="reference internal" href="d.html#glossary-d"><em>D</em></a>
| <a class="reference internal" href="e.html#glossary-e"><em>E</em></a>
| <a class="reference internal" href="f.html#glossary-f"><em>F</em></a>
| <a class="reference internal" href="g.html#glossary-g"><em>G</em></a>
| <a class="reference internal" href="h.html#glossary-h"><em>H</em></a>
| <a class="reference internal" href="#glossary-i"><em>I</em></a>
| J
| <a class="reference internal" href="k.html#glossary-k"><em>K</em></a>
| <a class="reference internal" href="l.html#glossary-l"><em>L</em></a>
| <a class="reference internal" href="m.html#glossary-m"><em>M</em></a>
| <a class="reference internal" href="n.html#glossary-n"><em>N</em></a>
| <a class="reference internal" href="o.html#glossary-o"><em>O</em></a>
| <a class="reference internal" href="p.html#glossary-p"><em>P</em></a>
| <a class="reference internal" href="q.html#glossary-q"><em>Q</em></a>
| <a class="reference internal" href="r.html#glossary-r"><em>R</em></a>
| <a class="reference internal" href="s.html#glossary-s"><em>S</em></a>
| <a class="reference internal" href="t.html#glossary-t"><em>T</em></a>
| <a class="reference internal" href="u.html#glossary-u"><em>U</em></a>
| <a class="reference internal" href="v.html#glossary-v"><em>V</em></a>
| <a class="reference internal" href="w.html#glossary-w"><em>W</em></a>
| X
| Y
| <a class="reference internal" href="z.html#glossary-z"><em>Z</em></a></p>
<dl class="glossary docutils">
<dt id="term-immediate-data">immediate data</dt>
<dd><p class="first">Immediate data is the representation of a <a class="reference internal" href="v.html#term-value-object"><em class="xref std std-term">value object</em></a>
as one or more machine <a class="reference internal" href="w.html#term-word"><em class="xref std std-term">words</em></a>, as a register, or
as a field in an instruction.</p>
<p>Immediate data takes its name from the value of the object
being immediately available, rather than requiring a
<a class="reference internal" href="l.html#term-load"><em class="xref std std-term">load</em></a> or indirection through a <a class="reference internal" href="r.html#term-reference"><em class="xref std std-term">reference</em></a>.</p>
<div class="admonition-similar-term admonition">
<p class="first admonition-title">Similar term</p>
<p class="last"><a class="reference internal" href="u.html#term-unboxed"><em class="xref std std-term">unboxed</em></a>.</p>
</div>
<div class="admonition-opposite-term last admonition">
<p class="first admonition-title">Opposite terms</p>
<p class="last"><a class="reference internal" href="b.html#term-boxed"><em class="xref std std-term">boxed</em></a>, <a class="reference internal" href="r.html#term-reference"><em class="xref std std-term">reference</em></a>, <a class="reference internal" href="p.html#term-pointer"><em class="xref std std-term">pointer</em></a>.</p>
</div>
</dd>
<dt id="term-immune-set">immune set</dt>
<dd><p class="first">The set of <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">objects</em></a> which are not
<a class="reference internal" href="c.html#term-condemned-set"><em class="xref std std-term">condemned</em></a>.</p>
<div class="admonition-opposite-term last admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="c.html#term-condemned-set"><em class="xref std std-term">condemned set</em></a>.</p>
</div>
</dd>
<dt id="term-immutable">immutable</dt>
<dd><p class="first">In some programming languages, <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">objects</em></a> of
some types are immutable, that is, they cannot be modified.
For example, in Standard <a class="reference internal" href="../mmref/lang.html#term-ml"><em class="xref std std-term">ML</em></a>, only arrays and refs are
mutable; all other objects are immutable.</p>
<p>This property can be very useful for <a class="reference internal" href="g.html#term-garbage-collection"><em class="xref std std-term">garbage
collection</em></a>. For instance, no immutable object may contain a
<a class="reference internal" href="r.html#term-reference"><em class="xref std std-term">reference</em></a> to an object younger than itself, and no
immutable object will appear in a <a class="reference internal" href="r.html#term-remembered-set"><em class="xref std std-term">remembered set</em></a>.
Garbage collectors for these languages often take advantage of
this property.</p>
<p>In lazy languages, the evaluation of an expression may require
an object of a different size, and adjustment of references
may take place. This means that, although objects might be
immutable at the language level, they are not immutable at the
implementation level, and may contain references to younger
objects.</p>
<div class="admonition-opposite-term admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="m.html#term-mutable"><em class="xref std std-term">mutable</em></a>.</p>
</div>
<div class="admonition-see-also last admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="g.html#term-generational-garbage-collection"><em class="xref std std-term">generational garbage collection</em></a>.</p>
</div>
</dd>
<dt id="term-immutable-object">immutable object</dt>
<dd><div class="admonition-see first last admonition">
<p class="first admonition-title">See</p>
<p class="last"><a class="reference internal" href="v.html#term-value-object"><em class="xref std std-term">value object</em></a>.</p>
</div>
</dd>
<dt id="term-in-band-header">in-band header</dt>
<dd><div class="admonition-also-known-as first admonition">
<p class="first admonition-title">Also known as</p>
<p class="last"><em>frame</em>, <em>header</em>.</p>
</div>
<p>Some <a class="reference internal" href="m.html#term-memory-manager"><em class="xref std std-term">memory managers</em></a> <a class="reference internal" href="a.html#term-allocate"><em class="xref std std-term">allocate</em></a>
a fixed amount more than is necessary for each <a class="reference internal" href="b.html#term-block"><em class="xref std std-term">block</em></a>
and use it to store information such as the size of the block
or a <a class="reference internal" href="t.html#term-tag"><em class="xref std std-term">tag</em></a>. This extra memory is known as an <em>in-band
header</em> or a <em>frame</em></p>
<p>This is a form of <a class="reference internal" href="#term-internal-fragmentation"><em class="xref std std-term">internal fragmentation</em></a>, although
sometimes, <a class="reference internal" href="a.html#term-alignment"><em class="xref std std-term">alignment</em></a> requirements result in free space
for the header.</p>
<p>Storing control information <em>in-band</em> often results in bad
<a class="reference internal" href="l.html#term-locality-of-reference"><em class="xref std std-term">locality</em></a>, particularly for
<a class="reference internal" href="f.html#term-free-1"><em class="xref std std-term">deallocation</em></a>.</p>
<div class="admonition-opposite-term admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="o.html#term-out-of-band-header"><em class="xref std std-term">out-of-band header</em></a>.</p>
</div>
<div class="admonition-see-also last admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="s.html#term-stack-frame"><em class="xref std std-term">stack frame</em></a>, <a class="reference internal" href="a.html#term-activation-frame"><em class="xref std std-term">activation frame</em></a>.</p>
</div>
</dd>
<dt id="term-in-parameter">in parameter</dt>
<dd><p class="first">A function parameter that supplies data from the caller to the
function. (The usual case in <a class="reference internal" href="../mmref/lang.html#term-c"><em class="xref std std-term">C</em></a>.)</p>
<div class="admonition-opposite-term last admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="o.html#term-out-parameter"><em class="xref std std-term">out parameter</em></a>.</p>
</div>
</dd>
<dt id="term-in-out-parameter">in/out parameter</dt>
<dd><p class="first">A function parameter that is both an <a class="reference internal" href="#term-in-parameter"><em class="xref std std-term">in parameter</em></a> an
<a class="reference internal" href="o.html#term-out-parameter"><em class="xref std std-term">out parameter</em></a>.</p>
<div class="admonition-in-the-mps last admonition">
<p class="first admonition-title">In the MPS</p>
<p class="last">In/out parameters are given names ending with <tt class="docutils literal"><span class="pre">_io</span></tt>. See
<a class="reference internal" href="../topic/interface.html#topic-interface"><em>Interface conventions</em></a>.</p>
</div>
</dd>
<dt id="term-incremental-garbage-collection">incremental garbage collection</dt>
<dd><p class="first">Some <a class="reference internal" href="t.html#term-tracing-garbage-collection"><em class="xref std std-term">tracing garbage collection</em></a> algorithms can pause
in the middle of a <a class="reference internal" href="c.html#term-collection-cycle"><em class="xref std std-term">collection cycle</em></a> while the
<a class="reference internal" href="m.html#term-mutator"><em class="xref std std-term">mutator</em></a> continues, without ending up with inconsistent
data. Such collectors can operate incrementally and are
suitable for use in an interactive system.</p>
<p>Primitive garbage <a class="reference internal" href="g.html#term-garbage-collector"><em class="xref std std-term">collectors<sup>(1)</sup></em></a>,
once they start a <a class="reference internal" href="c.html#term-collection-cycle"><em class="xref std std-term">collection cycle</em></a>, must either finish
the task, or abandon all their work so far. This is often an
appropriate restriction, but is unacceptable when the system
must guarantee response times; for example, in systems with a
user interface and in real-time hardware control systems. Such
systems might use incremental garbage collection so that the
time-critical processing and the garbage collection can
proceed effectively in parallel, without wasted effort.</p>
<div class="admonition-similar-term admonition">
<p class="first admonition-title">Similar term</p>
<p class="last"><a class="reference internal" href="p.html#term-parallel-garbage-collection"><em class="xref std std-term">parallel garbage collection</em></a>.</p>
</div>
<div class="admonition-opposite-term admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="s.html#term-stop-and-copy-collection"><em class="xref std std-term">stop-and-copy collection</em></a>.</p>
</div>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="t.html#term-tri-color-marking"><em class="xref std std-term">tri-color marking</em></a>, <a class="reference internal" href="b.html#term-barrier-1"><em class="xref std std-term">barrier<sup>(1)</sup></em></a>.</p>
</div>
<div class="admonition-related-publication last admonition">
<p class="first admonition-title">Related publications</p>
<p class="last"><a class="reference internal" href="../mmref/bib.html#ael88"><em>Appel et al. (1988)</em></a>, <a class="reference internal" href="../mmref/bib.html#bds91"><em>Boehm et al. (1991)</em></a>.</p>
</div>
</dd>
<dt id="term-incremental-update">incremental update</dt>
<dd><p class="first">Incremental-update algorithms for <a class="reference internal" href="t.html#term-trace"><em class="xref std std-term">tracing</em></a>,
<a class="reference internal" href="#term-incremental-garbage-collection"><em class="xref std std-term">incremental garbage collection</em></a> note changes made by
the <a class="reference internal" href="m.html#term-mutator"><em class="xref std std-term">mutator</em></a> to the <a class="reference internal" href="g.html#term-graph"><em class="xref std std-term">graph</em></a> of <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">objects</em></a>
and update the <a class="reference internal" href="c.html#term-collector-2"><em class="xref std std-term">collector<sup>(2)</sup></em></a> state to make it
correctly trace the new graph.</p>
<p>In order for the collector to miss a <a class="reference internal" href="r.html#term-reachable"><em class="xref std std-term">reachable</em></a>
<a class="reference internal" href="o.html#term-object"><em class="xref std std-term">object</em></a>, the following two conditions need to hold at
some point during tracing:</p>
<ol class="arabic simple">
<li>The mutator stores a <a class="reference internal" href="r.html#term-reference"><em class="xref std std-term">reference</em></a> to a <a class="reference internal" href="w.html#term-white"><em class="xref std std-term">white</em></a>
object into a <a class="reference internal" href="b.html#term-black"><em class="xref std std-term">black</em></a> object.</li>
<li>All paths from any <a class="reference internal" href="g.html#term-gray"><em class="xref std std-term">gray</em></a> objects to that white
object are destroyed.</li>
</ol>
<p>Incremental-update algorithms ensure the first condition
cannot occur, by painting either the black or the white object
gray (see <a class="reference internal" href="../mmref/bib.html#pirinen98"><em>Pirinen (1998)</em></a> for details).</p>
<p>They are so called because they incrementally update the
collector&#8217;s view of the graph to track changes made by the
mutator.</p>
<div class="admonition-historical-note admonition">
<p class="first admonition-title">Historical note</p>
<p class="last">This distinction between incremental update and
snapshot at the beginning was first introduced for
write-barrier algorithms, but it applies to any type of
tracing algorithm.</p>
</div>
<div class="admonition-opposite-term admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="s.html#term-snapshot-at-the-beginning"><em class="xref std std-term">snapshot at the beginning</em></a>.</p>
</div>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="t.html#term-tri-color-marking"><em class="xref std std-term">tri-color marking</em></a>, <a class="reference internal" href="s.html#term-strong-tri-color-invariant"><em class="xref std std-term">strong tri-color invariant</em></a>, <a class="reference internal" href="b.html#term-barrier-1"><em class="xref std std-term">barrier<sup>(1)</sup></em></a>.</p>
</div>
<div class="admonition-related-publication last admonition">
<p class="first admonition-title">Related publications</p>
<p class="last"><a class="reference internal" href="../mmref/bib.html#wil94"><em>Wilson (1994)</em></a>, <a class="reference internal" href="../mmref/bib.html#pirinen98"><em>Pirinen (1998)</em></a>.</p>
</div>
</dd>
<dt id="term-indefinite-extent">indefinite extent</dt>
<dd><p class="first">An <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">object</em></a> has indefinite extent if its
<a class="reference internal" href="l.html#term-lifetime"><em class="xref std std-term">lifetime</em></a> is independent of the block or function-call
structure of the program.</p>
<p>The <a class="reference internal" href="l.html#term-lifetime"><em class="xref std std-term">lifetime</em></a> of such an object can sometimes be
determined by the programmer, and specified by <a class="reference internal" href="f.html#term-free-1"><em class="xref std std-term">freeing</em></a> the object explicitly. This becomes harder to do
correctly as the program becomes more complex, especially if
objects are passed across module boundaries, or if
higher-order functions are used. In some languages it is
impossible to determine the extent at compile-time. In these
situations, a <a class="reference internal" href="g.html#term-garbage-collector"><em class="xref std std-term">garbage collector</em></a> can be used to
<a class="reference internal" href="r.html#term-recycle"><em class="xref std std-term">recycle</em></a> objects whose <a class="reference internal" href="l.html#term-lifetime"><em class="xref std std-term">lifetime</em></a> has come to an
end.</p>
<div class="admonition-opposite-term last admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="d.html#term-dynamic-extent"><em class="xref std std-term">dynamic extent</em></a>.</p>
</div>
</dd>
<dt id="term-indexed-fit">indexed fit</dt>
<dd><p class="first">A class of <a class="reference internal" href="a.html#term-allocation-mechanism"><em class="xref std std-term">allocation mechanisms</em></a> that use an indexing
data structure, such as a tree or hash table, to identify
suitable <a class="reference internal" href="f.html#term-free-block"><em class="xref std std-term">free blocks</em></a>, according to the
<a class="reference internal" href="a.html#term-allocation-policy"><em class="xref std std-term">allocation policy</em></a>. For instance, a tree ordered by
block size may be used to implement the <a class="reference internal" href="b.html#term-best-fit"><em class="xref std std-term">best fit</em></a>
policy.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="a.html#term-allocation-mechanism"><em class="xref std std-term">allocation mechanism</em></a>, <a class="reference internal" href="a.html#term-allocation-policy"><em class="xref std std-term">allocation policy</em></a>, <a class="reference internal" href="s.html#term-sequential-fit"><em class="xref std std-term">sequential fit</em></a>, <a class="reference internal" href="b.html#term-bitmapped-fit"><em class="xref std std-term">bitmapped fit</em></a>.</p>
</div>
<div class="admonition-related-publication last admonition">
<p class="first admonition-title">Related publication</p>
<p class="last"><a class="reference internal" href="../mmref/bib.html#wil95"><em>Wilson et al. (1995)</em></a>.</p>
</div>
</dd>
<dt id="term-indirect-method">indirect method</dt>
<dd><p class="first">Indirect methods of <a class="reference internal" href="a.html#term-automatic-memory-management"><em class="xref std std-term">automatic memory management</em></a> are
those in which the information necessary to determine whether
an <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">object</em></a> can be <a class="reference internal" href="r.html#term-reclaim"><em class="xref std std-term">reclaimed</em></a> is not
stored in or associated with that object, but is derived from
other objects.</p>
<p>Indirect methods detect <a class="reference internal" href="g.html#term-garbage"><em class="xref std std-term">garbage</em></a> by <a class="reference internal" href="t.html#term-trace"><em class="xref std std-term">tracing</em></a> <a class="reference internal" href="r.html#term-reachable"><em class="xref std std-term">reachable</em></a> objects.</p>
<p>Indirect methods cannot always reclaim <a class="reference internal" href="m.html#term-memory-2"><em class="xref std std-term">memory<sup>(2)</sup></em></a> as
soon as it becomes <a class="reference internal" href="d.html#term-dead"><em class="xref std std-term">dead</em></a>, because it may be necessary
to inspect many other objects to determine this. However, not
having to store and update information on each object may
reduce the overhead for the <a class="reference internal" href="c.html#term-collector-1"><em class="xref std std-term">collector<sup>(1)</sup></em></a>. In
<a class="reference internal" href="d.html#term-distributed-garbage-collection"><em class="xref std std-term">distributed garbage collection</em></a>, this can reduce the
amount of communication between processors.</p>
<div class="admonition-similar-term admonition">
<p class="first admonition-title">Similar term</p>
<p class="last"><a class="reference internal" href="t.html#term-tracing-garbage-collection"><em class="xref std std-term">tracing garbage collection</em></a>.</p>
</div>
<div class="admonition-opposite-term admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="d.html#term-direct-method"><em class="xref std std-term">direct method</em></a>.</p>
</div>
<div class="admonition-related-publication last admonition">
<p class="first admonition-title">Related publication</p>
<p class="last"><a class="reference internal" href="../mmref/bib.html#jones12"><em>Jones et al. (2012)</em></a>.</p>
</div>
</dd>
<dt id="term-infant-mortality">infant mortality</dt>
<dd><div class="admonition-see first last admonition">
<p class="first admonition-title">See</p>
<p class="last"><a class="reference internal" href="g.html#term-generational-hypothesis"><em class="xref std std-term">generational hypothesis</em></a>.</p>
</div>
</dd>
<dt id="term-inline-allocation-1">inline allocation<sup>(1)</sup></dt>
<dd><p class="first">Allocation of objects by inline code, that is, without calling
an allocation function. This is vital for performance in
languages that allocate many small objects.</p>
<div class="admonition-in-the-mps last admonition">
<p class="first admonition-title">In the MPS</p>
<p class="last">This is achieved by the
<a class="reference internal" href="../topic/allocation.html#topic-allocation-point-protocol"><em>Allocation point protocol</em></a>.</p>
</div>
</dd>
<dt id="term-inline-allocation-2">inline allocation<sup>(2)</sup></dt>
<dd>Allocation of child objects inside their parent, as opposed
to allocating child objects on the <a class="reference internal" href="h.html#term-heap"><em class="xref std std-term">heap</em></a> and storing
<a class="reference internal" href="p.html#term-pointer"><em class="xref std std-term">pointers</em></a> to them in the parent.</dd>
<dt id="term-inter-generational-pointer">inter-generational pointer</dt>
<dd><p class="first">An inter-generational pointer is a <a class="reference internal" href="r.html#term-reference"><em class="xref std std-term">reference</em></a> that is
stored in an <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">object</em></a> in one <a class="reference internal" href="g.html#term-generation"><em class="xref std std-term">generation</em></a> and
references an object in another generation.</p>
<p>If the referent&#8217;s generation is <a class="reference internal" href="c.html#term-condemned-set"><em class="xref std std-term">condemned</em></a> and the referrer&#8217;s generation is not, then the reference
is important in two ways. First, the reference keeps the
referent <a class="reference internal" href="l.html#term-live"><em class="xref std std-term">alive</em></a>, so the referrer must be
<a class="reference internal" href="s.html#term-scan"><em class="xref std std-term">scanned</em></a> during the <a class="reference internal" href="c.html#term-collection-cycle"><em class="xref std std-term">collection cycle</em></a>.
Second, the reference must always refer to the referent, so if
the referent is moved, then the referrer must be updated.</p>
<p>During a collection, the only objects in non-condemned areas
that must be scanned are the ones that contain
inter-generational pointers. <a class="reference internal" href="g.html#term-generational-garbage-collection"><em class="xref std std-term">Generational garbage
collectors</em></a> make use of
<a class="reference internal" href="w.html#term-write-barrier"><em class="xref std std-term">write barriers</em></a> and data structures like <a class="reference internal" href="e.html#term-entry-table-2"><em class="xref std std-term">entry
tables<sup>(2)</sup></em></a>, <a class="reference internal" href="e.html#term-exit-table"><em class="xref std std-term">exit tables</em></a>, and <a class="reference internal" href="r.html#term-remembered-set"><em class="xref std std-term">remembered sets</em></a>
to track those objects at run-time.</p>
<p class="last">Inter-generational pointers can cause <a class="reference internal" href="f.html#term-floating-garbage"><em class="xref std std-term">floating
garbage</em></a>: even if both referrer and referent die, the
inter-generational pointer will stop the referent from being
reclaimed until the referrer&#8217;s generation is condemned.</p>
</dd>
<dt id="term-interior-pointer">interior pointer</dt>
<dd><div class="admonition-also-known-as first admonition">
<p class="first admonition-title">Also known as</p>
<p class="last"><em>derived pointer</em>.</p>
</div>
<p>An <em>interior pointer</em> is a pointer to <a class="reference internal" href="m.html#term-memory-2"><em class="xref std std-term">memory<sup>(2)</sup></em></a>
occupied by an <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">object</em></a> which does not point to the
start location. Also called a <em>derived pointer</em> when it&#8217;s
derived from a <a class="reference internal" href="b.html#term-base-pointer"><em class="xref std std-term">base pointer</em></a>.</p>
<p>A <a class="reference internal" href="p.html#term-pointer"><em class="xref std std-term">pointer</em></a> to an object will usually take as its value
the <a class="reference internal" href="a.html#term-address"><em class="xref std std-term">address</em></a> of the start of that object.</p>
<p>It is common to have interior pointers into string buffers or
to embedded structures. A <a class="reference internal" href="s.html#term-suballocator"><em class="xref std std-term">suballocator</em></a> may place a
<a class="reference internal" href="#term-in-band-header"><em class="xref std std-term">header</em></a> at the start of each object
and pass on an interior pointer.</p>
<div class="admonition-relevance-to-memory-management admonition">
<p class="first admonition-title">Relevance to memory management</p>
<p class="last">In a system where interior pointers are used, the
<a class="reference internal" href="g.html#term-garbage-collector"><em class="xref std std-term">garbage collector</em></a> must be able to <a class="reference internal" href="m.html#term-marking"><em class="xref std std-term">mark</em></a> an object as <a class="reference internal" href="r.html#term-reachable"><em class="xref std std-term">reachable</em></a> without being
told the start of the object. In a system where interior
pointers are not used, the collector should either ignore
them (in particular, if it is <a class="reference internal" href="s.html#term-scan"><em class="xref std std-term">scanning</em></a>
<a class="reference internal" href="c.html#term-conservative-garbage-collection"><em class="xref std std-term">conservatively</em></a>)
and not retain <a class="reference internal" href="g.html#term-garbage"><em class="xref std std-term">garbage</em></a> because of them, or
possibly report them as bugs.</p>
</div>
<div class="admonition-opposite-term last admonition">
<p class="first admonition-title">Opposite term</p>
<p class="last"><a class="reference internal" href="b.html#term-base-pointer"><em class="xref std std-term">base pointer</em></a>.</p>
</div>
</dd>
<dt id="term-internal-fragmentation">internal fragmentation</dt>
<dd><p class="first">Internal <a class="reference internal" href="f.html#term-fragmentation"><em class="xref std std-term">fragmentation</em></a> is where the <a class="reference internal" href="m.html#term-memory-manager"><em class="xref std std-term">memory
manager</em></a> <a class="reference internal" href="a.html#term-allocate"><em class="xref std std-term">allocates</em></a> more for each allocation
than is actually requested. There are three reasons for this:
<a class="reference internal" href="p.html#term-padding"><em class="xref std std-term">padding</em></a>; <a class="reference internal" href="b.html#term-buddy-system"><em class="xref std std-term">buddy system</em></a>; <a class="reference internal" href="#term-in-band-header"><em class="xref std std-term">in-band headers</em></a>.</p>
<div class="admonition-see-also last admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="e.html#term-external-fragmentation"><em class="xref std std-term">external fragmentation</em></a>.</p>
</div>
</dd>
<dt id="term-invalid-page-fault">invalid page fault</dt>
<dd><p class="first">An exception when using <a class="reference internal" href="v.html#term-virtual-memory"><em class="xref std std-term">virtual memory</em></a> resulting
from an access to a virtual memory location for which no
translation is defined.</p>
<p>This is usually an error, often, anachronistically, known as a
<a class="reference internal" href="s.html#term-segmentation-violation"><em class="xref std std-term">segmentation violation</em></a>.</p>
<div class="admonition-similar-term admonition">
<p class="first admonition-title">Similar term</p>
<p class="last"><a class="reference internal" href="b.html#term-bus-error"><em class="xref std std-term">bus error</em></a>.</p>
</div>
<div class="admonition-see-also last admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last"><a class="reference internal" href="p.html#term-page-fault"><em class="xref std std-term">page fault</em></a>.</p>
</div>
</dd>
<dt id="term-inverted-page-table"><span id="term-20"></span>inverted page table<br />inverted page-table</dt>
<dd><p class="first">In a <a class="reference internal" href="v.html#term-virtual-memory"><em class="xref std std-term">virtual memory</em></a> system, conventional
<a class="reference internal" href="p.html#term-page-table"><em class="xref std std-term">page tables</em></a> have an entry for every
<a class="reference internal" href="p.html#term-page"><em class="xref std std-term">page</em></a> in the <a class="reference internal" href="v.html#term-virtual-address-space"><em class="xref std std-term">virtual address space</em></a>. An
<em>inverted page table</em> has only as many entries as there are
pages in <a class="reference internal" href="p.html#term-physical-memory-1"><em class="xref std std-term">physical memory<sup>(1)</sup></em></a>, and uses a hash lookup
to translate <a class="reference internal" href="v.html#term-virtual-address"><em class="xref std std-term">virtual addresses</em></a> to
<a class="reference internal" href="p.html#term-physical-address"><em class="xref std std-term">physical addresses</em></a> in nearly
constant time.</p>
<p>The entire virtual address space of each process is described
in an auxiliary structure, typically a B*-tree, that can
efficiently store contiguous, sparse, or large <a class="reference internal" href="a.html#term-address-space"><em class="xref std std-term">address
space</em></a> descriptions. This auxiliary structure may itself be
paged to avoid permanently consuming <a class="reference internal" href="p.html#term-physical-memory-1"><em class="xref std std-term">physical memory<sup>(1)</sup></em></a> resources.</p>
<p>Inverted page tables are ideal for schemes that store
information about <a class="reference internal" href="o.html#term-object"><em class="xref std std-term">objects</em></a> in the high-order
bits of their <a class="reference internal" href="a.html#term-address"><em class="xref std std-term">address</em></a>. Such schemes may perform poorly
with conventional page tables as the sparse address space may
cause the page table structures to become so large as to
compete with the program <a class="reference internal" href="w.html#term-working-set"><em class="xref std std-term">working set</em></a> for
<a class="reference internal" href="p.html#term-physical-memory-1"><em class="xref std std-term">physical memory<sup>(1)</sup></em></a>.</p>
<div class="admonition-historical-note last admonition">
<p class="first admonition-title">Historical note</p>
<p class="last">The <a class="reference internal" href="../mmref/lang.html#term-lisp-machine"><em class="xref std std-term">Lisp Machine</em></a> was an early workstation that
used an inverted page table with hardware lookup. The
UltraSPARC, PowerPC, and IA-64 architectures all include
inverted page tables. Some implementations of these
architectures have hardware-assisted lookup.</p>
</div>
</dd>
<dt id="term-is-forwarded-method">is-forwarded method</dt>
<dd><div class="admonition-in-the-mps first last admonition">
<p class="first admonition-title">In the MPS</p>
<p class="last">A <a class="reference internal" href="f.html#term-format-method"><em class="xref std std-term">format method</em></a> that is called by a <a class="reference internal" href="m.html#term-moving-garbage-collector"><em class="xref std std-term">moving</em></a> <a class="reference internal" href="p.html#term-pool"><em class="xref std std-term">pool</em></a> to determine if a
<a class="reference internal" href="f.html#term-formatted-object"><em class="xref std std-term">formatted object</em></a> is a <a class="reference internal" href="f.html#term-forwarding-object"><em class="xref std std-term">forwarding object</em></a>,
and if so, to return the address where the object was
moved to. See <a class="reference internal" href="../topic/format.html#mps_fmt_isfwd_t" title="mps_fmt_isfwd_t"><tt class="xref c c-type docutils literal"><span class="pre">mps_fmt_isfwd_t</span></tt></a>.</p>
</div>
</dd>
</dl>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.png" alt="Logo"/>
</a></p>
<h4>Previous topic</h4>
<p class="topless"><a href="h.html"
title="previous chapter">Memory Management Glossary: H</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="k.html"
title="next chapter">Memory Management Glossary: K</a></p><h4>Downloads</h4>
<p class="topless">
<a href="http://www.ravenbrook.com/project/mps/release/1.111.0/">MPS Kit release 1.111.0</a><br>
<a href="http://www.ravenbrook.com/project/mps/release/">All MPS Kit releases</a>
</p>
<h4>Issues</h4>
<p class="topless">
<a href="http://www.ravenbrook.com/project/mps/issue/?action=list&amp;view=status%3dopen&amp;display=Job:Priority:Title&amp;sort=Priority">Known issues</a><br>
<a href="http://www.ravenbrook.com/project/mps/issue/?action=fixed&release_fixed=1.111.0">Issues fixed in release 1.111.0</a>
</p><h4>Contact us</h4>
<p class="topless"><a href="mailto:mps-questions@ravenbrook.com">mps-questions@ravenbrook.com</a></p>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="k.html" title="Memory Management Glossary: K"
>next</a> |</li>
<li class="right" >
<a href="h.html" title="Memory Management Glossary: H"
>previous</a> |</li>
<li><a href="../index.html">Memory Pool System 1.111.0 documentation</a> &raquo;</li>
<li><a href="index.html" >Memory Management Glossary</a> &raquo;</li>
</ul>
</div>
<div class="footer">
&copy; <a href="../copyright.html">Copyright</a> 2013, Ravenbrook Limited.
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
</div>
</body>
</html>