mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-01-05 03:20:39 -08:00
639 lines
No EOL
53 KiB
HTML
639 lines
No EOL
53 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>5. Frequently Asked Questions — 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="Bibliography" href="bib.html" />
|
||
<link rel="prev" title="4. Memory management in various languages" href="lang.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="bib.html" title="Bibliography"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="lang.html" title="4. Memory management in various languages"
|
||
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="frequently-asked-questions">
|
||
<span id="mmref-faq"></span><h1>5. Frequently Asked Questions<a class="headerlink" href="#frequently-asked-questions" title="Permalink to this headline">¶</a></h1>
|
||
<p>This is a list of questions that represent the problems people often
|
||
have with memory management. Some answers appear below, with links to
|
||
helpful supporting material, such as the <a class="reference internal" href="../glossary/index.html#glossary"><em>Memory Management Glossary</em></a>, the
|
||
<a class="reference internal" href="bib.html#bibliography"><em>Bibliography</em></a>, and external sites. For a full explanation of any
|
||
terms used, see the glossary.</p>
|
||
<div class="section" id="c-specific-questions">
|
||
<h2>5.1. C-specific questions<a class="headerlink" href="#c-specific-questions" title="Permalink to this headline">¶</a></h2>
|
||
<div class="section" id="can-i-use-garbage-collection-in-c">
|
||
<h3>5.1.1. Can I use garbage collection in C?<a class="headerlink" href="#can-i-use-garbage-collection-in-c" title="Permalink to this headline">¶</a></h3>
|
||
<p>Yes. Various <a class="reference internal" href="../glossary/c.html#term-conservative-garbage-collection"><em class="xref std std-term">conservative garbage collectors</em></a> for <a class="reference internal" href="lang.html#term-c"><em class="xref std std-term">C</em></a> exist as add-on libraries.</p>
|
||
<div class="admonition-related-link admonition">
|
||
<p class="first admonition-title">Related link</p>
|
||
<p class="last"><a class="reference external" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm–Weiser collector</a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-do-i-need-to-test-the-return-value-from-malloc-surely-it-always-succeeds">
|
||
<h3>5.1.2. Why do I need to test the return value from <tt class="docutils literal"><span class="pre">malloc</span></tt>? Surely it always succeeds?<a class="headerlink" href="#why-do-i-need-to-test-the-return-value-from-malloc-surely-it-always-succeeds" title="Permalink to this headline">¶</a></h3>
|
||
<p>For small programs, and during light testing, it is true that
|
||
<a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a> usually succeeds. Unfortunately, there are all sorts of
|
||
unpredictable reasons why <a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a> might fail one day; for
|
||
example:</p>
|
||
<ul class="simple">
|
||
<li>someone uses your program for a far larger data set than you
|
||
anticipated;</li>
|
||
<li>your program is running on a machine with less memory than you
|
||
expected;</li>
|
||
<li>the machine your program is running on is heavily loaded.</li>
|
||
</ul>
|
||
<p>In this case, <a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a> will return <tt class="docutils literal"><span class="pre">NULL</span></tt>, and your program
|
||
will attempt to store data by resolving the null pointer. This might
|
||
cause your program to exit immediately with a helpful message, but it
|
||
is more likely to provoke mysterious problems later on.</p>
|
||
<p>If you want your code to be robust, and to stand the test of time, you
|
||
must check all error or status codes that may be returned by functions
|
||
you call, especially those in other libraries, such as the C run-time
|
||
library.</p>
|
||
<p>If you really don’t want to check the return value from
|
||
<a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a>, and you don’t want your program to behave mysteriously
|
||
when out of memory, wrap <a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a> in something like this:</p>
|
||
<div class="highlight-c"><div class="highlight"><pre><span class="cp">#include <stdio.h></span>
|
||
<span class="cp">#include <stdlib.h></span>
|
||
|
||
<span class="kt">void</span> <span class="o">*</span><span class="nf">my_malloc</span><span class="p">(</span><span class="kt">size_t</span> <span class="n">size</span><span class="p">)</span>
|
||
<span class="p">{</span>
|
||
<span class="kt">void</span> <span class="o">*</span><span class="n">p</span> <span class="o">=</span> <span class="n">malloc</span><span class="p">(</span><span class="n">size</span><span class="p">);</span>
|
||
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">p</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">fputs</span><span class="p">(</span><span class="s">"Out of memory.</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">stderr</span><span class="p">);</span>
|
||
<span class="n">exit</span><span class="p">(</span><span class="n">EXIT_FAILURE</span><span class="p">);</span>
|
||
<span class="p">}</span>
|
||
|
||
<span class="k">return</span> <span class="n">p</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Undefined behavior is worth eliminating even in small programs.</p>
|
||
</div>
|
||
<div class="section" id="what-s-the-point-of-having-a-garbage-collector-why-not-use-malloc-and-free">
|
||
<h3>5.1.3. What’s the point of having a garbage collector? Why not use <tt class="docutils literal"><span class="pre">malloc</span></tt> and <tt class="docutils literal"><span class="pre">free</span></tt>?<a class="headerlink" href="#what-s-the-point-of-having-a-garbage-collector-why-not-use-malloc-and-free" title="Permalink to this headline">¶</a></h3>
|
||
<p><a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">Manual memory management</em></a>, such as <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>, forces the programmer to keep track of which memory
|
||
is still required, and who is responsible for freeing it. This works
|
||
for small programs without internal interfaces, but becomes a rich
|
||
source of bugs in larger programs, and is a serious problem for
|
||
interface abstraction.</p>
|
||
<p><a class="reference internal" href="../glossary/a.html#term-automatic-memory-management"><em class="xref std std-term">Automatic memory management</em></a> frees the programmer from these
|
||
concerns, making it easier for him to code in the language of his
|
||
problem, rather than the tedious details of the implementation.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a></p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="what-s-wrong-with-ansi-malloc-in-the-c-library">
|
||
<h3>5.1.4. What’s wrong with ANSI <tt class="docutils literal"><span class="pre">malloc</span></tt> in the C library?<a class="headerlink" href="#what-s-wrong-with-ansi-malloc-in-the-c-library" title="Permalink to this headline">¶</a></h3>
|
||
<p><a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">Malloc</em></a> provides a very basic <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>
|
||
service. However, it does not provide the following things, which may
|
||
be desirable in your memory manager:</p>
|
||
<ul class="simple">
|
||
<li>high performance for specified block sizes;</li>
|
||
<li><a class="reference internal" href="../glossary/t.html#term-tagged-reference"><em class="xref std std-term">tagged references</em></a>;</li>
|
||
<li>simultaneous frees;</li>
|
||
<li><a class="reference internal" href="../glossary/l.html#term-locality-of-reference"><em class="xref std std-term">locality of reference</em></a> hints;</li>
|
||
<li><a class="reference internal" href="../glossary/f.html#term-formatted-object"><em class="xref std std-term">formatted objects</em></a>;</li>
|
||
<li>garbage collection;</li>
|
||
<li>deallocation of partial blocks;</li>
|
||
<li>multi-threading without synchronization;</li>
|
||
<li>inlined allocation code;</li>
|
||
<li><a class="reference internal" href="../glossary/f.html#term-finalization"><em class="xref std std-term">finalization</em></a>.</li>
|
||
</ul>
|
||
<p>Many of these can be added on top of <a class="reference internal" href="../glossary/m.html#term-malloc"><em class="xref std std-term">malloc</em></a>, but not with full
|
||
performance.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="id1">
|
||
<h2>5.2. C++-specific questions<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h2>
|
||
<div class="section" id="mmref-faq-c-gc">
|
||
<span id="id2"></span><h3>5.2.1. Can I use garbage collection in C++?<a class="headerlink" href="#mmref-faq-c-gc" title="Permalink to this headline">¶</a></h3>
|
||
<p>Yes. The C++ specification has always permitted garbage collection.
|
||
Bjarne Stroustrup (C++’s designer) has proposed that this be made
|
||
explicit in the standard. There exist various conservative and
|
||
semi-conservative garbage collectors for C++.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="lang.html#term-6"><em class="xref std std-term">C++</em></a>, <a class="reference internal" href="../glossary/c.html#term-conservative-garbage-collection"><em class="xref std std-term">conservative garbage collection</em></a>, <a class="reference internal" href="../glossary/s.html#term-semi-conservative-garbage-collection"><em class="xref std std-term">semi-conservative garbage collection</em></a>.</p>
|
||
</div>
|
||
<div class="admonition-related-link admonition">
|
||
<p class="first admonition-title">Related link</p>
|
||
<p class="last"><a class="reference external" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm–Weiser collector</a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-is-delete-so-slow">
|
||
<h3>5.2.2. Why is <tt class="docutils literal"><span class="pre">delete</span></tt> so slow?<a class="headerlink" href="#why-is-delete-so-slow" title="Permalink to this headline">¶</a></h3>
|
||
<p>Often <tt class="docutils literal"><span class="pre">delete</span></tt> must perform a more complex task than simply freeing
|
||
the memory associated with an object; this is known as
|
||
<a class="reference internal" href="../glossary/f.html#term-finalization"><em class="xref std std-term">finalization</em></a>. Finalization typically involves releasing any
|
||
resources indirectly associated with the object, such as files that
|
||
must be closed or ancillary objects that must be finalized themselves.
|
||
This may involve traversing memory that has been unused for some time
|
||
and hence is <a class="reference internal" href="../glossary/p.html#term-paged-out"><em class="xref std std-term">paged out</em></a>.</p>
|
||
<p>With <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a> (such as <tt class="docutils literal"><span class="pre">new</span></tt> and
|
||
<tt class="docutils literal"><span class="pre">delete</span></tt>), it is perfectly possible for the <a class="reference internal" href="../glossary/f.html#term-free-1"><em class="xref std std-term">deallocation</em></a> operation to vary in complexity. Some systems do quite a
|
||
lot of processing on freed blocks to <a class="reference internal" href="../glossary/c.html#term-coalesce"><em class="xref std std-term">coalesce</em></a> adjacent blocks,
|
||
sort free blocks by size (in a <a class="reference internal" href="../glossary/b.html#term-buddy-system"><em class="xref std std-term">buddy system</em></a>, say), or sort the
|
||
<a class="reference internal" href="../glossary/f.html#term-free-list"><em class="xref std std-term">free list</em></a> by address. In the last case, deallocating blocks in
|
||
address order (or sometimes reverse address order) can result in poor
|
||
performance.</p>
|
||
</div>
|
||
<div class="section" id="what-happens-if-you-use-class-libraries-that-leak-memory">
|
||
<h3>5.2.3. What happens if you use class libraries that leak memory?<a class="headerlink" href="#what-happens-if-you-use-class-libraries-that-leak-memory" title="Permalink to this headline">¶</a></h3>
|
||
<p>In <a class="reference internal" href="lang.html#term-6"><em class="xref std std-term">C++</em></a>, it may be that class libraries expect you to call
|
||
<tt class="docutils literal"><span class="pre">delete</span></tt> on objects they create, to invoke the <a class="reference internal" href="../glossary/d.html#term-destructor-2"><em class="xref std std-term">destructor<sup>(2)</sup></em></a>. Check the interface documentation.</p>
|
||
<p>Failing this, if there is a genuine <a class="reference internal" href="../glossary/m.html#term-memory-leak"><em class="xref std std-term">memory leak</em></a> in a class
|
||
library for which you don’t have the source, then the only thing you
|
||
can try is to add a <a class="reference internal" href="../glossary/g.html#term-garbage-collector"><em class="xref std std-term">garbage collector</em></a>. The Boehm–Weiser
|
||
collector will work with C++.</p>
|
||
<div class="admonition-related-link admonition">
|
||
<p class="first admonition-title">Related link</p>
|
||
<p class="last"><a class="reference external" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm–Weiser collector</a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="can-t-i-get-all-the-benefits-of-garbage-collection-using-c-constructors-and-destructors">
|
||
<h3>5.2.4. Can’t I get all the benefits of garbage collection using C++ constructors and destructors?<a class="headerlink" href="#can-t-i-get-all-the-benefits-of-garbage-collection-using-c-constructors-and-destructors" title="Permalink to this headline">¶</a></h3>
|
||
<p>Carefully designed <a class="reference internal" href="lang.html#term-6"><em class="xref std std-term">C++</em></a> <a class="reference internal" href="../glossary/c.html#term-constructor-2"><em class="xref std std-term">constructors<sup>(2)</sup></em></a> and
|
||
<a class="reference internal" href="../glossary/d.html#term-destructor-2"><em class="xref std std-term">destructors<sup>(2)</sup></em></a> can go a long way towards easing the pain of
|
||
<a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>. Objects can know how to deallocate
|
||
all their associated resources, including dependent objects (by
|
||
recursive destruction). This means that clients of a class library do
|
||
not need to worry about how to free resources allocated on their
|
||
behalf.</p>
|
||
<p>Unfortunately, they still need to worry about <em>when</em> to free such
|
||
resources. Unless all objects are allocated for precisely one purpose,
|
||
and referred to from just one place (or from within one compound data
|
||
structure that will be destroyed atomically), then a piece of code
|
||
that has finished with an object cannot determine that it is safe to
|
||
call the destructor; it cannot be certain (especially when working
|
||
with other people’s code) that there is not another piece of code that
|
||
will try to use the object subsequently.</p>
|
||
<p>This is where garbage collection has the advantage, because it can
|
||
determine when a given object is no longer of interest to anyone (or
|
||
at least when there are no more references to it). This neatly avoids
|
||
the problems of having multiple copies of the same data or complex
|
||
conditional destruction. The program can construct objects and store
|
||
references to them anywhere it finds convenient; the garbage collector
|
||
will deal with all the problems of data sharing.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="common-objections-to-garbage-collection">
|
||
<h2>5.3. Common objections to garbage collection<a class="headerlink" href="#common-objections-to-garbage-collection" title="Permalink to this headline">¶</a></h2>
|
||
<div class="section" id="what-languages-use-garbage-collection">
|
||
<h3>5.3.1. What languages use garbage collection?<a class="headerlink" href="#what-languages-use-garbage-collection" title="Permalink to this headline">¶</a></h3>
|
||
<p><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-5"><em class="xref std std-term">C#</em></a>, <a class="reference internal" href="lang.html#term-python"><em class="xref std std-term">Python</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>, …
|
||
the list goes on. It surprises many to learn that many implementations
|
||
of <a class="reference internal" href="lang.html#term-basic"><em class="xref std std-term">BASIC</em></a> use <a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a> to manage character
|
||
strings efficiently.</p>
|
||
<p><a class="reference internal" href="lang.html#term-6"><em class="xref std std-term">C++</em></a> is sometimes characterized as the last holdout against
|
||
garbage collection, but this is not accurate. See
|
||
<a class="reference internal" href="#mmref-faq-c-gc"><em>Can I use garbage collection in C++?</em></a></p>
|
||
<p>The notion of <a class="reference internal" href="../glossary/a.html#term-automatic-memory-management"><em class="xref std std-term">automatic memory management</em></a> has stood the test
|
||
of time and is becoming a standard part of modern programming
|
||
environments. Some will say “the right tool for the right job”,
|
||
rejecting automatic memory management in some cases; few today are
|
||
bold enough to suggest that there is never a place for garbage
|
||
collection among tools of the modern programmer—either as part of a
|
||
language or as an add-on component.</p>
|
||
</div>
|
||
<div class="section" id="what-s-the-advantage-of-garbage-collection">
|
||
<h3>5.3.2. What’s the advantage of garbage collection?<a class="headerlink" href="#what-s-the-advantage-of-garbage-collection" title="Permalink to this headline">¶</a></h3>
|
||
<p><a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">Garbage collection</em></a> frees you from having to keep track of
|
||
which part of your program is responsible for the deallocation of
|
||
which memory. This freedom from tedious and error-prone bookkeeping
|
||
allows you to concentrate on the problem you are trying to solve,
|
||
without introducing additional problems of implementation.</p>
|
||
<p>This is particularly important in large-scale or highly modular programs,
|
||
especially libraries, because the problems of manual memory management
|
||
often dominate interface complexity. Additionally, garbage collection can reduce the amount of memory used because the interface problems of manual memory management are often solved by creating extra copies of data.</p>
|
||
<p>In terms of performance, garbage collection is often faster than manual memory management. It can also improve performance indirectly, by increasing <a class="reference internal" href="../glossary/l.html#term-locality-of-reference"><em class="xref std std-term">locality of reference</em></a> and hence reducing the size of the <a class="reference internal" href="../glossary/w.html#term-working-set"><em class="xref std std-term">working set</em></a>, and decreasing <a class="reference internal" href="../glossary/p.html#term-paging"><em class="xref std std-term">paging</em></a>.</p>
|
||
<div class="admonition-related-publication admonition">
|
||
<p class="first admonition-title">Related publication</p>
|
||
<p class="last"><a class="reference internal" href="bib.html#zorn92"><em>Zorn (1992)</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="programs-with-gc-are-huge-and-bloated-gc-isn-t-suitable-for-small-programs-or-systems">
|
||
<h3>5.3.3. Programs with GC are huge and bloated; GC isn’t suitable for small programs or systems<a class="headerlink" href="#programs-with-gc-are-huge-and-bloated-gc-isn-t-suitable-for-small-programs-or-systems" title="Permalink to this headline">¶</a></h3>
|
||
<p>While it is true that the major advantages of <a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage
|
||
collection</em></a> are only seen in complex systems, there is no reason for
|
||
garbage collection to introduce any significant overhead at any scale.
|
||
The data structures associated with garbage collection compare
|
||
favorably in size with those required for <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory
|
||
management</em></a>.</p>
|
||
<p>Some older systems gave garbage collection a bad name in terms of
|
||
space or time overhead, but many modern techniques exist that make
|
||
such overheads a thing of the past. Additionally, some garbage
|
||
collectors are designed to work best in certain problem domains, such
|
||
as large programs; these may perform poorly outside their target
|
||
environment.</p>
|
||
<div class="admonition-related-publication admonition">
|
||
<p class="first admonition-title">Related publication</p>
|
||
<p class="last"><a class="reference internal" href="bib.html#zorn92"><em>Zorn (1992)</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="i-can-t-use-gc-because-i-can-t-afford-to-have-my-program-pause">
|
||
<h3>5.3.4. I can’t use GC because I can’t afford to have my program pause<a class="headerlink" href="#i-can-t-use-gc-because-i-can-t-afford-to-have-my-program-pause" title="Permalink to this headline">¶</a></h3>
|
||
<p>While early garbage collectors had to complete without interruption
|
||
and hence would pause observably, many techniques are now available to
|
||
ensure that modern collectors can be unobtrusive.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/i.html#term-incremental-garbage-collection"><em class="xref std std-term">incremental garbage collection</em></a>, <a class="reference internal" href="../glossary/p.html#term-parallel-garbage-collection"><em class="xref std std-term">parallel garbage collection</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="isn-t-it-much-cheaper-to-use-reference-counts-rather-than-garbage-collection">
|
||
<h3>5.3.5. Isn’t it much cheaper to use reference counts rather than garbage collection?<a class="headerlink" href="#isn-t-it-much-cheaper-to-use-reference-counts-rather-than-garbage-collection" title="Permalink to this headline">¶</a></h3>
|
||
<p>No, updating <a class="reference internal" href="../glossary/r.html#term-reference-counting"><em class="xref std std-term">reference counts</em></a> is quite
|
||
expensive, and they have a couple of problems:</p>
|
||
<ul class="simple">
|
||
<li>They can’t cope with <a class="reference internal" href="../glossary/c.html#term-cyclic-data-structure"><em class="xref std std-term">cyclic data structures</em></a>; that is, sets
|
||
of objects that are referred to only by objects in that set, but
|
||
that don’t have a zero reference count.</li>
|
||
<li>Reference counting gets more expensive if you have to allow for the
|
||
count overflowing.</li>
|
||
</ul>
|
||
<p>There are many systems that use reference counts, and avoid the
|
||
problems described above by using a conventional <a class="reference internal" href="../glossary/g.html#term-garbage-collector"><em class="xref std std-term">garbage
|
||
collector</em></a> to complement it. This is usually done for real-time
|
||
benefits. Unfortunately, experience shows that this is generally less
|
||
efficient than implementing a proper real-time garbage collector,
|
||
except in the case where most reference counts are one.</p>
|
||
<div class="admonition-related-publication admonition">
|
||
<p class="first admonition-title">Related publication</p>
|
||
<p class="last"><a class="reference internal" href="bib.html#wise93"><em>Wise (1993)</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="isn-t-gc-unreliable-i-ve-heard-that-gcs-often-kill-the-program">
|
||
<h3>5.3.6. Isn’t GC unreliable? I’ve heard that GCs often kill the program<a class="headerlink" href="#isn-t-gc-unreliable-i-ve-heard-that-gcs-often-kill-the-program" title="Permalink to this headline">¶</a></h3>
|
||
<p><a class="reference internal" href="../glossary/g.html#term-garbage-collector"><em class="xref std std-term">Garbage collectors</em></a> usually have to manipulate vulnerable data
|
||
structures and must often use poorly-documented, low-level interfaces.
|
||
Additionally, any garbage collection problems may not be detected
|
||
until some time later. These factors combine to make most garbage
|
||
collection bugs severe in effect, hard to reproduce, and difficult to
|
||
work around.</p>
|
||
<p>On the other hand, commercial garbage collection code will generally
|
||
be heavily tested and widely used, which implies it must be reliable.
|
||
It will be hard to match that reliability in a manual memory manager
|
||
written for one program, especially given that <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory
|
||
management</em></a> doesn’t scale as well as the automatic variety.</p>
|
||
<p>In addition, bugs in the compiler or run-time (or application if the
|
||
language is as low-level as <a class="reference internal" href="lang.html#term-c"><em class="xref std std-term">C</em></a>) can corrupt the heap in ways
|
||
that only the garbage collector will detect later. The collector is
|
||
blamed because it found the corruption. This is a classic case of
|
||
shooting the messenger.</p>
|
||
</div>
|
||
<div class="section" id="i-ve-heard-that-gc-uses-twice-as-much-memory">
|
||
<h3>5.3.7. I’ve heard that GC uses twice as much memory<a class="headerlink" href="#i-ve-heard-that-gc-uses-twice-as-much-memory" title="Permalink to this headline">¶</a></h3>
|
||
<p>This may be true of primitive collectors (like the <a class="reference internal" href="../glossary/t.html#term-two-space-collector"><em class="xref std std-term">two-space
|
||
collector</em></a>), but this is not generally true of garbage collection. The
|
||
data structures used for garbage collection need be no larger than
|
||
those for <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>.</p>
|
||
</div>
|
||
<div class="section" id="doesn-t-garbage-collection-make-programs-slow">
|
||
<h3>5.3.8. Doesn’t garbage collection make programs slow?<a class="headerlink" href="#doesn-t-garbage-collection-make-programs-slow" title="Permalink to this headline">¶</a></h3>
|
||
<p>No. <a class="reference internal" href="bib.html#zorn92"><em>Benjamin Zorn (1992)</em></a> found that:</p>
|
||
<blockquote>
|
||
<div>the CPU overhead of <a class="reference internal" href="../glossary/c.html#term-conservative-garbage-collection"><em class="xref std std-term">conservative garbage collection</em></a> is
|
||
comparable to that of explicit storage management techniques. […]
|
||
Conservative garbage collection performs faster than some explicit
|
||
algorithms and slower than others, the relative performance being
|
||
largely dependent on the program.</div></blockquote>
|
||
<p>Note also that the version of the conservative collector used in this
|
||
paper is now rather old and the collector has been much improved since
|
||
then.</p>
|
||
</div>
|
||
<div class="section" id="manual-memory-management-gives-me-control-it-doesn-t-pause">
|
||
<h3>5.3.9. Manual memory management gives me control—it doesn’t pause<a class="headerlink" href="#manual-memory-management-gives-me-control-it-doesn-t-pause" title="Permalink to this headline">¶</a></h3>
|
||
<p>It is possible for <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a> to pause for
|
||
considerable periods, either on <a class="reference internal" href="../glossary/a.html#term-allocate"><em class="xref std std-term">allocation</em></a> or
|
||
<a class="reference internal" href="../glossary/f.html#term-free-1"><em class="xref std std-term">deallocation</em></a>. It certainly gives no guarantees
|
||
about performance, in general.</p>
|
||
<p>With <a class="reference internal" href="../glossary/a.html#term-automatic-memory-management"><em class="xref std std-term">automatic memory management</em></a>, such as <a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage
|
||
collection</em></a>, modern techniques can give guarantees about interactive
|
||
pause times, and so on.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/i.html#term-incremental-garbage-collection"><em class="xref std std-term">incremental garbage collection</em></a>, <a class="reference internal" href="../glossary/p.html#term-parallel-garbage-collection"><em class="xref std std-term">parallel garbage collection</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="miscellaneous">
|
||
<h2>5.4. Miscellaneous<a class="headerlink" href="#miscellaneous" title="Permalink to this headline">¶</a></h2>
|
||
<div class="section" id="why-does-my-disk-rattle-so-much">
|
||
<h3>5.4.1. Why does my disk rattle so much?<a class="headerlink" href="#why-does-my-disk-rattle-so-much" title="Permalink to this headline">¶</a></h3>
|
||
<p>When you are using a <a class="reference internal" href="../glossary/v.html#term-virtual-memory"><em class="xref std std-term">virtual memory</em></a> system, the computer may
|
||
have to fetch <a class="reference internal" href="../glossary/p.html#term-page"><em class="xref std std-term">pages</em></a> of memory from disk before they can be
|
||
accessed. If the total <a class="reference internal" href="../glossary/w.html#term-working-set"><em class="xref std std-term">working set</em></a> of your active programs
|
||
exceeds the <a class="reference internal" href="../glossary/p.html#term-physical-memory-1"><em class="xref std std-term">physical memory<sup>(1)</sup></em></a> available, <a class="reference internal" href="../glossary/p.html#term-paging"><em class="xref std std-term">paging</em></a> will
|
||
happen continually, your disk will rattle, and performance will
|
||
degrade significantly. The only solutions are to install more physical
|
||
memory, run fewer programs at the same time, or tune the memory
|
||
requirements of your programs.</p>
|
||
<p>The problem is aggravated because virtual memory systems approximate
|
||
the theoretical working set with the set of pages on which the working
|
||
set lies. If the actual working set is spread out onto a large number
|
||
of pages, then the working page-set is large.</p>
|
||
<p>When objects that refer to each other are distant in memory, this 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>. This happens either
|
||
because the program’s designer did not worry about this, or the memory
|
||
manager used in the program doesn’t permit the designer to do anything
|
||
about it.</p>
|
||
<p>Note that <a class="reference internal" href="../glossary/c.html#term-copying-garbage-collection"><em class="xref std std-term">copying garbage collection</em></a> can dynamically organize
|
||
your data according to the program’s reference patterns and thus
|
||
mitigate this problem.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/t.html#term-thrash"><em class="xref std std-term">thrash</em></a></p>
|
||
</div>
|
||
<div class="admonition-related-publication admonition">
|
||
<p class="first admonition-title">Related publication</p>
|
||
<p class="last"><a class="reference internal" href="bib.html#denning68"><em>Denning (1968)</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="where-can-i-find-out-more-about-garbage-collection">
|
||
<h3>5.4.2. Where can I find out more about garbage collection?<a class="headerlink" href="#where-can-i-find-out-more-about-garbage-collection" title="Permalink to this headline">¶</a></h3>
|
||
<p>Many modern languages have <a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a> built in, and
|
||
the language documentation should give details. For some other
|
||
languages, garbage collection can be added, for example via the
|
||
Boehm–Weiser collector.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a></p>
|
||
</div>
|
||
<div class="admonition-related-publication admonition">
|
||
<p class="first admonition-title">Related publications</p>
|
||
<p class="last"><a class="reference internal" href="bib.html#jones12"><em>Jones et al. (2012)</em></a>, <a class="reference internal" href="bib.html#wil94"><em>Wilson (1994)</em></a>.</p>
|
||
</div>
|
||
<div class="admonition-related-link admonition">
|
||
<p class="first admonition-title">Related link</p>
|
||
<p class="last"><a class="reference external" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm–Weiser collector</a>,
|
||
<a class="reference external" href="http://iecc.com/gclist/GC-faq.html">GC-LIST FAQ</a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="where-can-i-get-a-garbage-collector">
|
||
<h3>5.4.3. Where can I get a garbage collector?<a class="headerlink" href="#where-can-i-get-a-garbage-collector" title="Permalink to this headline">¶</a></h3>
|
||
<p>The Boehm–Weiser collector is suitable for C or C++. The best way to
|
||
get a garbage collector, however, is to program in a language that
|
||
provides garbage collection.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a></p>
|
||
</div>
|
||
<div class="admonition-related-link admonition">
|
||
<p class="first admonition-title">Related link</p>
|
||
<p class="last"><a class="reference external" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm–Weiser collector</a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-does-my-program-use-so-much-memory">
|
||
<h3>5.4.4. Why does my program use so much memory?<a class="headerlink" href="#why-does-my-program-use-so-much-memory" title="Permalink to this headline">¶</a></h3>
|
||
<p>If you are using <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a> (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>), it is likely that
|
||
your program is failing to free memory blocks after it stops using
|
||
them. When your code allocates memory on the heap, there is an implied
|
||
responsibility to free that memory. If a function uses heap memory for
|
||
returning data, you must decide who takes on that responsibility. Pay
|
||
special attention to the interfaces between functions and modules.
|
||
Remember to check what happens to allocated memory in the event of an
|
||
error or an exception.</p>
|
||
<p>If you are using <a class="reference internal" href="../glossary/a.html#term-automatic-memory-management"><em class="xref std std-term">automatic memory management</em></a> (almost certainly
|
||
<a class="reference internal" href="../glossary/g.html#term-garbage-collection"><em class="xref std std-term">garbage collection</em></a>), it is probable that your code is
|
||
remembering some blocks that it will never use in future. This is
|
||
known as the difference between <a class="reference internal" href="../glossary/l.html#term-live"><em class="xref std std-term">liveness</em></a> and
|
||
<a class="reference internal" href="../glossary/r.html#term-reachable"><em class="xref std std-term">reachability</em></a>. Consider clearing variables that
|
||
refer to large blocks or networks of blocks, when the data structure
|
||
is no longer required.</p>
|
||
</div>
|
||
<div class="section" id="i-use-a-library-and-my-program-grows-every-time-i-call-it-why">
|
||
<h3>5.4.5. I use a library, and my program grows every time I call it. Why?<a class="headerlink" href="#i-use-a-library-and-my-program-grows-every-time-i-call-it-why" title="Permalink to this headline">¶</a></h3>
|
||
<p>If you are using <a class="reference internal" href="../glossary/m.html#term-manual-memory-management"><em class="xref std std-term">manual memory management</em></a>, it is likely that
|
||
the library is allocating data structures on the heap every time it is
|
||
used, but that they are not being freed. Check the interface
|
||
documentation for the library; it may expect you to take some action
|
||
when you have finished with returned data. It may be necessary to
|
||
close down the library and re-initialize it to recover allocated
|
||
memory.</p>
|
||
<p>Unfortunately, it is all too possible that the library has a memory
|
||
management bug. In this case, unless you have the source code, there
|
||
is little you can do except report the problem to the supplier. It may
|
||
be possible to add a garbage collector to your language, and this
|
||
might solve your problems.</p>
|
||
<p>With a <a class="reference internal" href="../glossary/g.html#term-garbage-collector"><em class="xref std std-term">garbage collector</em></a>, sometimes objects are retained
|
||
because there is a reference to them from some global data structure.
|
||
Although the library might not make any further use of the objects,
|
||
the collector must retain the objects because they are still
|
||
<a class="reference internal" href="../glossary/r.html#term-reachable"><em class="xref std std-term">reachable</em></a>.</p>
|
||
<p>If you know that a particular reference will never be used in future,
|
||
it can be worthwhile to overwrite it. This means that the collector
|
||
will not retain the referred object because of that reference. Other
|
||
references to the same object will keep it <a class="reference internal" href="../glossary/l.html#term-live"><em class="xref std std-term">alive</em></a>, so
|
||
your program doesn’t need to determine whether the object itself will
|
||
ever be accessed in future. This should be done judiciously, using the
|
||
garbage collector’s tools to find what objects are being retained and
|
||
why.</p>
|
||
<p>If your garbage collector is <a class="reference internal" href="../glossary/g.html#term-generational-garbage-collection"><em class="xref std std-term">generational</em></a>, it is possible that you are suffering from <a class="reference internal" href="../glossary/p.html#term-premature-tenuring"><em class="xref std std-term">premature tenuring</em></a>, which can often be solved by tuning the collector or using a separate memory area for the library.</p>
|
||
</div>
|
||
<div class="section" id="should-i-write-my-own-memory-allocator-to-make-my-program-fast">
|
||
<h3>5.4.6. Should I write my own memory allocator to make my program fast?<a class="headerlink" href="#should-i-write-my-own-memory-allocator-to-make-my-program-fast" title="Permalink to this headline">¶</a></h3>
|
||
<p>If you are sure that your program is spending a large proportion of
|
||
its time in <a class="reference internal" href="../glossary/m.html#term-memory-management"><em class="xref std std-term">memory management</em></a>, and you know what you’re doing,
|
||
then it is certainly possible to improve performance by writing a
|
||
<a class="reference internal" href="../glossary/s.html#term-suballocator"><em class="xref std std-term">suballocator</em></a>. On the other hand, advances in memory management
|
||
technology make it hard to keep up with software written by experts.
|
||
In general, improvements to memory management don’t make as much
|
||
difference to performance as improvements to the program algorithms.</p>
|
||
<p><a class="reference internal" href="bib.html#zorn92"><em>Benjamin Zorn (1992)</em></a> found that:</p>
|
||
<blockquote>
|
||
<div>In four of the programs investigated, the programmer felt
|
||
compelled to avoid using the general-purpose storage allocator by
|
||
writing type-specific allocation routines for the most common
|
||
object types in the program. […] The general conclusion […] is
|
||
that programmer optimizations in these programs were mostly
|
||
unnecessary. […] simply using a different algorithm
|
||
appears to improve the performance even more.</div></blockquote>
|
||
<p>and concluded:</p>
|
||
<blockquote>
|
||
<div>programmers, instead of spending time writing domain-specific
|
||
storage allocators, should consider using other publicly-available
|
||
implementations of storage management algorithms if the one they
|
||
are using performs poorly.</div></blockquote>
|
||
</div>
|
||
<div class="section" id="why-can-t-i-just-use-local-data-on-the-stack-or-in-global-variables">
|
||
<h3>5.4.7. Why can’t I just use local data on the stack or in global variables?<a class="headerlink" href="#why-can-t-i-just-use-local-data-on-the-stack-or-in-global-variables" title="Permalink to this headline">¶</a></h3>
|
||
<p>Global, or static, data is fixed size; it cannot grow in response to
|
||
the size or complexity of the data set received by a program.
|
||
Stack-allocated data doesn’t exist once you leave the function (or
|
||
program block) in which it was declared.</p>
|
||
<p>If your program’s memory requirements are entirely predictable and
|
||
fixed at compile-time, or you can structure your program to rely on
|
||
stack data only while it exists, then you can entirely avoid using
|
||
heap allocation. Note that, with some compilers, use of large global
|
||
memory blocks can bloat the object file size.</p>
|
||
<p>It may often seem simpler to allocate a global block that seems
|
||
“probably large enough” for any plausible data set, but this
|
||
simplification will almost certainly cause trouble sooner or later.</p>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/s.html#term-stack-allocation"><em class="xref std std-term">stack allocation</em></a>, <a class="reference internal" href="../glossary/h.html#term-heap-allocation"><em class="xref std std-term">heap allocation</em></a>, <a class="reference internal" href="../glossary/s.html#term-static-allocation"><em class="xref std std-term">static allocation</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="why-should-i-worry-about-virtual-memory-can-t-i-just-use-as-much-memory-as-i-want">
|
||
<h3>5.4.8. Why should I worry about virtual memory? Can’t I just use as much memory as I want?<a class="headerlink" href="#why-should-i-worry-about-virtual-memory-can-t-i-just-use-as-much-memory-as-i-want" title="Permalink to this headline">¶</a></h3>
|
||
<p>While <a class="reference internal" href="../glossary/v.html#term-virtual-memory"><em class="xref std std-term">virtual memory</em></a> can greatly increase your capacity to
|
||
store data, there are three problems typically experienced with it:</p>
|
||
<ul class="simple">
|
||
<li>It does not provide an unlimited amount of memory. In particular,
|
||
all memory that you actually allocate (as opposed to reserve) has to
|
||
be stored somewhere. Usually you must have disk space available for
|
||
all pages containing allocated memory. In a few systems, you can
|
||
subtract the available physical memory from the disk space required.
|
||
If the memory contains images of program or data files, then
|
||
<a class="reference internal" href="../glossary/f.html#term-file-mapping"><em class="xref std std-term">file mapping</em></a>, or assigning existing files to regions of the
|
||
virtual address space, can help considerably.</li>
|
||
<li>In most computers, there is a large difference in speed between main
|
||
memory and disk; running a program with a <a class="reference internal" href="../glossary/w.html#term-working-set"><em class="xref std std-term">working set</em></a> that
|
||
does not fit in physical memory almost always results in
|
||
unacceptable performance.</li>
|
||
<li>An additional problem with using unnecessary quantities of memory is
|
||
that poor <a class="reference internal" href="../glossary/l.html#term-locality-of-reference"><em class="xref std std-term">locality of reference</em></a> can result in heavy paging.</li>
|
||
</ul>
|
||
<div class="admonition-see-also admonition seealso">
|
||
<p class="first admonition-title">See also</p>
|
||
<p class="last"><a class="reference internal" href="../glossary/t.html#term-thrash"><em class="xref std std-term">thrash</em></a>.</p>
|
||
</div>
|
||
</div>
|
||
</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="#">5. Frequently Asked Questions</a><ul>
|
||
<li><a class="reference internal" href="#c-specific-questions">5.1. C-specific questions</a><ul>
|
||
<li><a class="reference internal" href="#can-i-use-garbage-collection-in-c">5.1.1. Can I use garbage collection in C?</a></li>
|
||
<li><a class="reference internal" href="#why-do-i-need-to-test-the-return-value-from-malloc-surely-it-always-succeeds">5.1.2. Why do I need to test the return value from <tt class="docutils literal"><span class="pre">malloc</span></tt>? Surely it always succeeds?</a></li>
|
||
<li><a class="reference internal" href="#what-s-the-point-of-having-a-garbage-collector-why-not-use-malloc-and-free">5.1.3. What’s the point of having a garbage collector? Why not use <tt class="docutils literal"><span class="pre">malloc</span></tt> and <tt class="docutils literal"><span class="pre">free</span></tt>?</a></li>
|
||
<li><a class="reference internal" href="#what-s-wrong-with-ansi-malloc-in-the-c-library">5.1.4. What’s wrong with ANSI <tt class="docutils literal"><span class="pre">malloc</span></tt> in the C library?</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id1">5.2. C++-specific questions</a><ul>
|
||
<li><a class="reference internal" href="#mmref-faq-c-gc">5.2.1. Can I use garbage collection in C++?</a></li>
|
||
<li><a class="reference internal" href="#why-is-delete-so-slow">5.2.2. Why is <tt class="docutils literal"><span class="pre">delete</span></tt> so slow?</a></li>
|
||
<li><a class="reference internal" href="#what-happens-if-you-use-class-libraries-that-leak-memory">5.2.3. What happens if you use class libraries that leak memory?</a></li>
|
||
<li><a class="reference internal" href="#can-t-i-get-all-the-benefits-of-garbage-collection-using-c-constructors-and-destructors">5.2.4. Can’t I get all the benefits of garbage collection using C++ constructors and destructors?</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#common-objections-to-garbage-collection">5.3. Common objections to garbage collection</a><ul>
|
||
<li><a class="reference internal" href="#what-languages-use-garbage-collection">5.3.1. What languages use garbage collection?</a></li>
|
||
<li><a class="reference internal" href="#what-s-the-advantage-of-garbage-collection">5.3.2. What’s the advantage of garbage collection?</a></li>
|
||
<li><a class="reference internal" href="#programs-with-gc-are-huge-and-bloated-gc-isn-t-suitable-for-small-programs-or-systems">5.3.3. Programs with GC are huge and bloated; GC isn’t suitable for small programs or systems</a></li>
|
||
<li><a class="reference internal" href="#i-can-t-use-gc-because-i-can-t-afford-to-have-my-program-pause">5.3.4. I can’t use GC because I can’t afford to have my program pause</a></li>
|
||
<li><a class="reference internal" href="#isn-t-it-much-cheaper-to-use-reference-counts-rather-than-garbage-collection">5.3.5. Isn’t it much cheaper to use reference counts rather than garbage collection?</a></li>
|
||
<li><a class="reference internal" href="#isn-t-gc-unreliable-i-ve-heard-that-gcs-often-kill-the-program">5.3.6. Isn’t GC unreliable? I’ve heard that GCs often kill the program</a></li>
|
||
<li><a class="reference internal" href="#i-ve-heard-that-gc-uses-twice-as-much-memory">5.3.7. I’ve heard that GC uses twice as much memory</a></li>
|
||
<li><a class="reference internal" href="#doesn-t-garbage-collection-make-programs-slow">5.3.8. Doesn’t garbage collection make programs slow?</a></li>
|
||
<li><a class="reference internal" href="#manual-memory-management-gives-me-control-it-doesn-t-pause">5.3.9. Manual memory management gives me control—it doesn’t pause</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#miscellaneous">5.4. Miscellaneous</a><ul>
|
||
<li><a class="reference internal" href="#why-does-my-disk-rattle-so-much">5.4.1. Why does my disk rattle so much?</a></li>
|
||
<li><a class="reference internal" href="#where-can-i-find-out-more-about-garbage-collection">5.4.2. Where can I find out more about garbage collection?</a></li>
|
||
<li><a class="reference internal" href="#where-can-i-get-a-garbage-collector">5.4.3. Where can I get a garbage collector?</a></li>
|
||
<li><a class="reference internal" href="#why-does-my-program-use-so-much-memory">5.4.4. Why does my program use so much memory?</a></li>
|
||
<li><a class="reference internal" href="#i-use-a-library-and-my-program-grows-every-time-i-call-it-why">5.4.5. I use a library, and my program grows every time I call it. Why?</a></li>
|
||
<li><a class="reference internal" href="#should-i-write-my-own-memory-allocator-to-make-my-program-fast">5.4.6. Should I write my own memory allocator to make my program fast?</a></li>
|
||
<li><a class="reference internal" href="#why-can-t-i-just-use-local-data-on-the-stack-or-in-global-variables">5.4.7. Why can’t I just use local data on the stack or in global variables?</a></li>
|
||
<li><a class="reference internal" href="#why-should-i-worry-about-virtual-memory-can-t-i-just-use-as-much-memory-as-i-want">5.4.8. Why should I worry about virtual memory? Can’t I just use as much memory as I want?</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="lang.html"
|
||
title="previous chapter">4. Memory management in various languages</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="bib.html"
|
||
title="next chapter">Bibliography</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="bib.html" title="Bibliography"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="lang.html" title="4. Memory management in various languages"
|
||
>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> 2012, Ravenbrook Limited.
|
||
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
|
||
</div>
|
||
</body>
|
||
</html> |