1
Fork 0
mirror of git://git.sv.gnu.org/emacs.git synced 2025-12-29 08:31:35 -08:00
emacs/mps/manual/html/mmref/begin.html
Richard Brooksby 8c4a4b127d Updated manual html
Copied from Perforce
 Change: 181622
 ServerID: perforce.ravenbrook.com
2013-05-08 14:07:56 +01:00

349 lines
No EOL
22 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>1. Overview &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="Introduction to memory management" href="index.html" />
<link rel="next" title="2. Allocation techniques" href="alloc.html" />
<link rel="prev" title="Introduction to memory management" href="index.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="alloc.html" title="2. Allocation techniques"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="index.html" title="Introduction to memory management"
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">Introduction to memory management</a> &raquo;</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="overview">
<span id="mmref-overview"></span><h1>1. Overview<a class="headerlink" href="#overview" title="Permalink to this headline"></a></h1>
<p>Memory management is a complex field of computer science and there are
many techniques being developed to make it more efficient. This guide
is designed to introduce you to some of the basic memory management
issues that programmers face.</p>
<p>This guide attempts to explain any terms it uses as it introduces
them. In addition, there is a <a class="reference internal" href="../glossary/index.html#glossary"><em>Memory Management Glossary</em></a> of memory management
terms that gives fuller information; some terms are linked to the
relevant entries.</p>
<p><a class="reference internal" href="../glossary/m.html#term-memory-management"><em class="xref std std-term">Memory management</em></a> is usually divided into three areas,
although the distinctions are a little fuzzy:</p>
<ul class="simple">
<li><a class="reference internal" href="#mmref-overview-hardware"><em>Hardware memory management</em></a></li>
<li><a class="reference internal" href="#mmref-overview-os"><em>Operating system memory management</em></a></li>
<li><a class="reference internal" href="#mmref-overview-app"><em>Application memory management</em></a></li>
</ul>
<p>These are described in more detail below. In most computer systems,
all three are present to some extent, forming layers between the
user&#8217;s program and the actual memory hardware. The Memory Management
Reference is mostly concerned with application memory management.</p>
<div class="section" id="hardware-memory-management">
<span id="mmref-overview-hardware"></span><h2>1.1. Hardware memory management<a class="headerlink" href="#hardware-memory-management" title="Permalink to this headline"></a></h2>
<p>Memory management at the hardware level is concerned with the
electronic devices that actually store data. This includes things like
<a class="reference internal" href="../glossary/r.html#term-ram"><em class="xref std std-term">RAM</em></a> and <a class="reference internal" href="../glossary/c.html#term-cache-1"><em class="xref std std-term">memory caches</em></a>.</p>
</div>
<div class="section" id="operating-system-memory-management">
<span id="mmref-overview-os"></span><h2>1.2. Operating system memory management<a class="headerlink" href="#operating-system-memory-management" title="Permalink to this headline"></a></h2>
<p>In the operating system, memory must be allocated to user programs,
and reused by other programs when it is no longer required. The
operating system can pretend that the computer has more memory than it
actually does, and also that each program has the machine&#8217;s memory to
itself; both of these are features of <a class="reference internal" href="../glossary/v.html#term-virtual-memory"><em class="xref std std-term">virtual memory</em></a> systems.</p>
</div>
<div class="section" id="application-memory-management">
<span id="mmref-overview-app"></span><h2>1.3. Application memory management<a class="headerlink" href="#application-memory-management" title="Permalink to this headline"></a></h2>
<p>Application memory management involves supplying the memory needed for
a program&#8217;s objects and data structures from the limited resources
available, and recycling that memory for reuse when it is no longer
required. Because application programs cannot in general predict in
advance how much memory they are going to require, they need
additional code to handle their changing memory requirements.</p>
<p>Application memory management combines two related tasks:</p>
<p><strong>Allocation</strong></p>
<blockquote>
<div>When the program requests a block of memory, the memory manager
must allocate that block out of the larger blocks it has received
from the operating system. The part of the memory manager that
does this is known as the <a class="reference internal" href="../glossary/a.html#term-allocator"><em class="xref std std-term">allocator</em></a>. There are many ways
to perform allocation, a few of which are discussed in
<a class="reference internal" href="alloc.html#mmref-alloc"><em>Allocation techniques</em></a>.</div></blockquote>
<p><strong>Recycling</strong></p>
<blockquote>
<div>When memory blocks have been allocated, but the data they contain
is no longer required by the program, then the blocks can be
recycled for reuse. There are two approaches to recycling memory:
either the programmer must decide when memory can be reused (known
as <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>); or the memory manager must
be able to work it out (known as <a class="reference internal" href="../glossary/a.html#term-automatic-memory-management"><em class="xref std std-term">automatic memory
management</em></a>). These are both described in more detail below.</div></blockquote>
<p>An application memory manager must usually work to several
constraints, such as:</p>
<p><strong>CPU overhead</strong></p>
<blockquote>
<div>The additional time taken by the memory manager while the program
is running.</div></blockquote>
<p><strong>Pause times</strong></p>
<blockquote>
<div><p>The time it takes for the memory manager to complete an operation
and return control to the program.</p>
<p>This affects the program&#8217;s ability to respond promptly to
interactive events, and also to any asynchronous event such as a
network connection.</p>
</div></blockquote>
<p><strong>Memory overhead</strong></p>
<blockquote>
<div>How much space is wasted for administration, rounding (known as
<a class="reference internal" href="../glossary/i.html#term-internal-fragmentation"><em class="xref std std-term">internal fragmentation</em></a>), and poor layout (known as
<a class="reference internal" href="../glossary/e.html#term-external-fragmentation"><em class="xref std std-term">external fragmentation</em></a>).</div></blockquote>
<p>Some of the common problems encountered in application memory
management are considered in the next section.</p>
</div>
<div class="section" id="memory-management-problems">
<span id="mmref-overview-problem"></span><h2>1.4. Memory management problems<a class="headerlink" href="#memory-management-problems" title="Permalink to this headline"></a></h2>
<p>The basic problem in managing memory is knowing when to keep the data
it contains, and when to throw it away so that the memory can be
reused. This sounds easy, but is, in fact, such a hard problem that it
is an entire field of study in its own right. In an ideal world, most
programmers wouldn&#8217;t have to worry about memory management issues.
Unfortunately, there are many ways in which poor memory management
practice can affect the robustness and speed of programs, both in
manual and in automatic memory management.</p>
<p>Typical problems include:</p>
<p><strong>Premature frees and dangling pointers</strong></p>
<blockquote>
<div>Many programs give up memory, but attempt to access it later and
crash or behave randomly. This condition is known as a
<a class="reference internal" href="../glossary/p.html#term-premature-free"><em class="xref std std-term">premature free</em></a>, and the surviving reference to the memory
is known as a <a class="reference internal" href="../glossary/d.html#term-dangling-pointer"><em class="xref std std-term">dangling pointer</em></a>. This is usually confined
to <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>.</div></blockquote>
<p><strong>Memory leak</strong></p>
<blockquote>
<div>Some programs continually allocate memory without ever giving it
up and eventually run out of memory. This condition is known as a
<a class="reference internal" href="../glossary/m.html#term-memory-leak"><em class="xref std std-term">memory leak</em></a>.</div></blockquote>
<p><strong>External fragmentation</strong></p>
<blockquote>
<div>A poor allocator can do its job of giving out and receiving blocks
of memory so badly that it can no longer give out big enough
blocks despite having enough spare memory. This is because the
free memory can become split into many small blocks, separated by
blocks still in use. This condition is known as <a class="reference internal" href="../glossary/e.html#term-external-fragmentation"><em class="xref std std-term">external
fragmentation</em></a>.</div></blockquote>
<p><strong>Poor locality of reference</strong></p>
<blockquote>
<div>Another problem with the layout of allocated blocks comes from the
way that modern hardware and operating system memory managers
handle memory: successive memory accesses are faster if they are
to nearby memory locations. If the memory manager places far apart
the blocks a program will use together, then this will cause
performance problems. This condition is known as poor
<a class="reference internal" href="../glossary/l.html#term-locality-of-reference"><em class="xref std std-term">locality of reference</em></a>.</div></blockquote>
<p><strong>Inflexible design</strong></p>
<blockquote>
<div>Memory managers can also cause severe performance problems if they
have been designed with one use in mind, but are used in a
different way. These problems occur because any memory management
solution tends to make assumptions about the way in which the
program is going to use memory, such as typical block sizes,
reference patterns, or lifetimes of objects. If these assumptions
are wrong, then the memory manager may spend a lot more time doing
bookkeeping work to keep up with what&#8217;s happening.</div></blockquote>
<p><strong>Interface complexity</strong></p>
<blockquote>
<div>If objects are passed between modules, then the interface design
must consider the management of their memory.</div></blockquote>
<p>A well-designed memory manager can make it easier to write debugging
tools, because much of the code can be shared. Such tools could
display objects, navigate links, validate objects, or detect abnormal
accumulations of certain object types or block sizes.</p>
</div>
<div class="section" id="manual-memory-management">
<span id="mmref-overview-manual"></span><h2>1.5. Manual memory management<a class="headerlink" href="#manual-memory-management" title="Permalink to this headline"></a></h2>
<p>Manual memory management is where the programmer has direct control
over when memory may be recycled. Usually this is either by explicit
calls to <a class="reference internal" href="../glossary/h.html#term-heap"><em class="xref std std-term">heap</em></a> management functions (for example,
<a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a> and <a class="reference internal" href="../glossary/f.html#term-free-2"><em class="xref std std-term">free<sup>(2)</sup></em></a> in <a class="reference internal" href="lang.html#term-c"><em class="xref std std-term">C</em></a>), or by language
constructs that affect the <a class="reference internal" href="../glossary/c.html#term-control-stack"><em class="xref std std-term">control stack</em></a> (such as local
variables). The key feature of a manual memory manager is that it
provides a way for the program to say, &#8220;Have this memory back; I&#8217;ve
finished with it&#8221;; the memory manager does not recycle any memory
without such an instruction.</p>
<p>The advantages of manual memory management are:</p>
<ul class="simple">
<li>it can be easier for the programmer to understand exactly what is
going on;</li>
<li>some manual memory managers perform better when there is a shortage
of memory.</li>
</ul>
<p>The disadvantages of manual memory management are:</p>
<ul class="simple">
<li>the programmer must write a lot of code to do repetitive bookkeeping
of memory;</li>
<li>memory management must form a significant part of any module interface;</li>
<li>manual memory management typically requires more memory overhead per
object;</li>
<li>memory management bugs are common.</li>
</ul>
<p>It is very common for programmers, faced with an inefficient or
inadequate manual memory manager, to write code to duplicate the
behavior of a memory manager, either by allocating large blocks and
splitting them for use, or by recycling blocks internally. Such code
is known as a <a class="reference internal" href="../glossary/s.html#term-suballocator"><em class="xref std std-term">suballocator</em></a>. Suballocators can take advantage
of special knowledge of program behavior, but are less efficient in
general than fixing the underlying allocator. Unless written by a
memory management expert, suballocators may be inefficient or
unreliable.</p>
<p>The following languages use mainly manual memory management in most
implementations, although many have <a class="reference internal" href="../glossary/c.html#term-conservative-garbage-collection"><em class="xref std std-term">conservative garbage
collection</em></a> extensions: <a class="reference internal" href="lang.html#term-algol"><em class="xref std std-term">Algol</em></a>; <a class="reference internal" href="lang.html#term-c"><em class="xref std std-term">C</em></a>; <a class="reference internal" href="lang.html#term-6"><em class="xref std std-term">C++</em></a>;
<a class="reference internal" href="lang.html#term-cobol"><em class="xref std std-term">COBOL</em></a>; <a class="reference internal" href="lang.html#term-fortran"><em class="xref std std-term">Fortran</em></a>; <a class="reference internal" href="lang.html#term-pascal"><em class="xref std std-term">Pascal</em></a>.</p>
</div>
<div class="section" id="automatic-memory-management">
<span id="mmref-overview-automatic"></span><h2>1.6. Automatic memory management<a class="headerlink" href="#automatic-memory-management" title="Permalink to this headline"></a></h2>
<p>Automatic memory management is a service, either as a part of the
language or as an extension, that automatically recycles memory that a
program would not otherwise use again. Automatic memory managers
(often known as garbage collectors, or simply collectors) usually do
their job by recycling blocks that are <a class="reference internal" href="../glossary/u.html#term-unreachable"><em class="xref std std-term">unreachable</em></a> from the
program variables (that is, blocks that cannot be reached by following
pointers).</p>
<p>The advantages of automatic memory management are:</p>
<ul class="simple">
<li>the programmer is freed to work on the actual problem;</li>
<li>module interfaces are cleaner;</li>
<li>there are fewer memory management bugs;</li>
<li>memory management is often more efficient.</li>
</ul>
<p>The disadvantages of automatic memory management are:</p>
<ul class="simple">
<li>memory may be retained because it is reachable, but won&#8217;t be used again;</li>
<li>automatic memory managers (currently) have limited availability.</li>
</ul>
<p>There are many ways of performing automatic recycling of memory, a few
of which are discussed in <a class="reference internal" href="recycle.html#mmref-recycle"><em>Recycling techniques</em></a>.</p>
<p>Most modern languages use mainly automatic memory management:
<a class="reference internal" href="lang.html#term-basic"><em class="xref std std-term">BASIC</em></a>, <a class="reference internal" href="lang.html#term-dylan"><em class="xref std std-term">Dylan</em></a>, Erlang, Haskell, <a class="reference internal" href="lang.html#term-java"><em class="xref std std-term">Java</em></a>,
<a class="reference internal" href="lang.html#term-javascript"><em class="xref std std-term">JavaScript</em></a>, <a class="reference internal" href="lang.html#term-lisp"><em class="xref std std-term">Lisp</em></a>, <a class="reference internal" href="lang.html#term-ml"><em class="xref std std-term">ML</em></a>, <a class="reference internal" href="lang.html#term-modula-3"><em class="xref std std-term">Modula-3</em></a>,
<a class="reference internal" href="lang.html#term-perl"><em class="xref std std-term">Perl</em></a>, <a class="reference internal" href="lang.html#term-postscript"><em class="xref std std-term">PostScript</em></a>, <a class="reference internal" href="lang.html#term-prolog"><em class="xref std std-term">Prolog</em></a>, Python,
<a class="reference internal" href="lang.html#term-scheme"><em class="xref std std-term">Scheme</em></a>, <a class="reference internal" href="lang.html#term-smalltalk"><em class="xref std std-term">Smalltalk</em></a>, etc.</p>
</div>
<div class="section" id="more-information">
<h2>1.7. More information<a class="headerlink" href="#more-information" title="Permalink to this headline"></a></h2>
<p>For more detailed information on the topics covered briefly above,
please have a look at the <a class="reference internal" href="../glossary/index.html#glossary"><em>Memory Management Glossary</em></a>. Books and research papers
are available on many specific techniques, and can be found via our
<a class="reference internal" href="bib.html#bibliography"><em>Bibliography</em></a>; particularly recommended are: <a class="reference internal" href="bib.html#wil94"><em>Wilson (1994)</em></a>, which is survey of garbage collection techniques;
<a class="reference internal" href="bib.html#wil95"><em>Wilson et al. (1995)</em></a>, which is a survey of allocation
techniques; and <a class="reference internal" href="bib.html#jones12"><em>Jones et al. (2012)</em></a>, which is a
handbook covering all aspects of garbage collection.</p>
</div>
</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>
<h3><a href="../index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">1. Overview</a><ul>
<li><a class="reference internal" href="#hardware-memory-management">1.1. Hardware memory management</a></li>
<li><a class="reference internal" href="#operating-system-memory-management">1.2. Operating system memory management</a></li>
<li><a class="reference internal" href="#application-memory-management">1.3. Application memory management</a></li>
<li><a class="reference internal" href="#memory-management-problems">1.4. Memory management problems</a></li>
<li><a class="reference internal" href="#manual-memory-management">1.5. Manual memory management</a></li>
<li><a class="reference internal" href="#automatic-memory-management">1.6. Automatic memory management</a></li>
<li><a class="reference internal" href="#more-information">1.7. More information</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="index.html"
title="previous chapter">Introduction to memory management</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="alloc.html"
title="next chapter">2. Allocation techniques</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="alloc.html" title="2. Allocation techniques"
>next</a> |</li>
<li class="right" >
<a href="index.html" title="Introduction to memory management"
>previous</a> |</li>
<li><a href="../index.html">Memory Pool System 1.111.0 documentation</a> &raquo;</li>
<li><a href="index.html" >Introduction to memory management</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>