mirror of
git://git.sv.gnu.org/emacs.git
synced 2025-12-29 08:31:35 -08:00
349 lines
No EOL
22 KiB
HTML
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 — 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> »</li>
|
|
<li><a href="index.html" accesskey="U">Introduction to memory management</a> »</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’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’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’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’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’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’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, “Have this memory back; I’ve
|
|
finished with it”; 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’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&view=status%3dopen&display=Job:Priority:Title&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> »</li>
|
|
<li><a href="index.html" >Introduction to memory management</a> »</li>
|
|
</ul>
|
|
</div>
|
|
<div class="footer">
|
|
© <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> |