mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-01-13 06:50:39 -08:00
410 lines
No EOL
30 KiB
HTML
410 lines
No EOL
30 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>6. Collection framework — 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="Design" href="index.html" />
|
|
<link rel="next" title="7. Configuration" href="config.html" />
|
|
<link rel="prev" title="5. Pool class interface" href="class-interface.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="config.html" title="7. Configuration"
|
|
accesskey="N">next</a> |</li>
|
|
<li class="right" >
|
|
<a href="class-interface.html" title="5. Pool class interface"
|
|
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">Design</a> »</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="document">
|
|
<div class="documentwrapper">
|
|
<div class="bodywrapper">
|
|
<div class="body">
|
|
|
|
<div class="section" id="collection-framework">
|
|
<span id="design.mps.collection"></span><h1>6. Collection framework<a class="headerlink" href="#collection-framework" title="Permalink to this headline">¶</a></h1>
|
|
<div class="section" id="introduction">
|
|
<h2>6.1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
|
|
<p><span class="target" id="design.mps.collection.intro"></span><a class="mpstag reference internal" href="#design.mps.collection.intro">.intro:</a> This document describes the Collection Framework. It’s a framework for
|
|
implementing garbage collection techniques and integrating them into a system
|
|
of collectors that all cooperate in recycling garbage.</p>
|
|
</div>
|
|
<div class="section" id="history">
|
|
<h2>6.2. History<a class="headerlink" href="#history" title="Permalink to this headline">¶</a></h2>
|
|
<p><span class="target" id="design.mps.collection.hist.0"></span><a class="mpstag reference internal" href="#design.mps.collection.hist.0">.hist.0:</a> Version 0 was a different document.</p>
|
|
<p><span class="target" id="design.mps.collection.hist.1"></span><a class="mpstag reference internal" href="#design.mps.collection.hist.1">.hist.1:</a> Version 1 was a different document.</p>
|
|
<p><span class="target" id="design.mps.collection.hist.2"></span><a class="mpstag reference internal" href="#design.mps.collection.hist.2">.hist.2:</a> Written in January and February 1998 by Pekka P.
|
|
Pirinen on the basis of the current implementation of the MPS,
|
|
analysis.async-gc, [that note on the independence of
|
|
collections] and analysis.tracer.</p>
|
|
</div>
|
|
<div class="section" id="overview">
|
|
<h2>6.3. Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
|
|
<p><span class="target" id="design.mps.collection.framework"></span><a class="mpstag reference internal" href="#design.mps.collection.framework">.framework:</a> MPS provides a framework that allows the
|
|
integration of many different types of GC strategies and provides many
|
|
of the basic services that those strategies use.</p>
|
|
<p><span class="target" id="design.mps.collection.framework.cover"></span><a class="mpstag reference internal" href="#design.mps.collection.framework.cover">.framework.cover:</a> The framework subsumes most major GC
|
|
strategies and allows many efficient techniques, like in-line
|
|
allocation or software barriers.</p>
|
|
<p><span class="target" id="design.mps.collection.framework.overhead"></span><a class="mpstag reference internal" href="#design.mps.collection.framework.overhead">.framework.overhead:</a> The overhead due to cooperation is low.
|
|
[But not non-existent. Can we say something useful about it?]</p>
|
|
<p><span class="target" id="design.mps.collection.framework.benefits"></span><a class="mpstag reference internal" href="#design.mps.collection.framework.benefits">.framework.benefits:</a> The ability to combine collectors
|
|
contributes significantly to the flexibility of the system. The
|
|
reduction in code duplication contributes to reliability and
|
|
integrity. The services of the framework make it easier to write new
|
|
MM strategies and collectors.</p>
|
|
<p><span class="target" id="design.mps.collection.framework.mpm"></span><a class="mpstag reference internal" href="#design.mps.collection.framework.mpm">.framework.mpm:</a> The Collection Framework is merely a part of
|
|
the structure of the MPM. See design.mps.architecture and
|
|
design.mps.arch [Those two documents should be combined
|
|
into one. Pekka 1998-01-15] for the big picture. Other notable
|
|
components that the MPM manages to integrate into a single framework
|
|
are manually-managed memory [another missing document here?] and
|
|
finalization services (see design.mps.finalize).</p>
|
|
<p><span class="target" id="design.mps.collection.see-also"></span><a class="mpstag reference internal" href="#design.mps.collection.see-also">.see-also:</a> This document assumes basic familiarity with the
|
|
ideas of pool (see design.mps.arch.pools) and segment (see
|
|
design.mps.seg.over).</p>
|
|
</div>
|
|
<div class="section" id="collection-abstractions">
|
|
<h2>6.4. Collection abstractions<a class="headerlink" href="#collection-abstractions" title="Permalink to this headline">¶</a></h2>
|
|
<div class="section" id="colours-scanning-and-fixing">
|
|
<h3>6.4.1. Colours, scanning and fixing<a class="headerlink" href="#colours-scanning-and-fixing" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.state"></span><a class="mpstag reference internal" href="#design.mps.collection.state">.state:</a> The framework knows about the three colours of the
|
|
tri-state abstraction and free blocks. Recording the state of each
|
|
object is the responsibility of the pool, but the framework gets told
|
|
about changes in the states and keeps track of colours in each
|
|
segment. Specifically, it records whether a segment might contain
|
|
white, grey and black objects with respect to each active trace (see
|
|
<a class="reference internal" href="#design.mps.collection.tracer">.tracer</a>) [black not currently implemented – Pekka
|
|
1998-01-04]. (A segment might contain objects of all colours at once,
|
|
or none.) This information is approximate, because when an object
|
|
changes colour, or dies, it usually is too expensive to determine if
|
|
it was the last object of its former colour.</p>
|
|
<p><span class="target" id="design.mps.collection.state.transitions"></span><a class="mpstag reference internal" href="#design.mps.collection.state.transitions">.state.transitions:</a> The possible state transitions are as
|
|
follows:</p>
|
|
<div class="highlight-c"><div class="highlight"><pre><span class="n">free</span> <span class="o">---</span><span class="n">alloc</span><span class="o">--></span> <span class="n">black</span> <span class="p">(</span><span class="n">or</span> <span class="n">grey</span><span class="p">)</span> <span class="n">or</span> <span class="n">white</span> <span class="n">or</span> <span class="n">none</span>
|
|
<span class="n">none</span> <span class="o">--</span><span class="n">condemn</span><span class="o">-></span> <span class="n">white</span>
|
|
<span class="n">none</span> <span class="o">--</span><span class="n">refine</span><span class="o">--></span> <span class="n">grey</span>
|
|
<span class="n">grey</span> <span class="o">---</span><span class="n">scan</span><span class="o">---></span> <span class="n">black</span>
|
|
<span class="n">white</span> <span class="o">----</span><span class="n">fix</span><span class="o">---></span> <span class="n">grey</span> <span class="p">(</span><span class="n">or</span> <span class="n">black</span><span class="p">)</span>
|
|
<span class="n">black</span> <span class="o">--</span><span class="n">revert</span><span class="o">--></span> <span class="n">grey</span>
|
|
<span class="n">white</span> <span class="o">--</span><span class="n">reclaim</span><span class="o">-></span> <span class="n">free</span>
|
|
<span class="n">black</span> <span class="o">--</span><span class="n">reclaim</span><span class="o">-></span> <span class="n">none</span>
|
|
</pre></div>
|
|
</div>
|
|
<p><span class="target" id="design.mps.collection.none-is-black"></span><a class="mpstag reference internal" href="#design.mps.collection.none-is-black">.none-is-black:</a> Outside of a trace, objects don’t really have
|
|
colour, but technically, the colour is black. Objects are only
|
|
allocated grey or white during a trace, and by the time the trace has
|
|
finished, they are either dead or black, like the other surviving
|
|
objects. We might then reuse the colour field for another trace, so
|
|
it’s convenient to set the colour to black when allocating outside a
|
|
trace. This means that refining the foundation
|
|
(analysis.tracer.phase.condemn.refine), actually turns
|
|
black segments grey, rather than vice versa, but the principle is the
|
|
same.</p>
|
|
<p><span class="target" id="design.mps.collection.scan-fix"></span><a class="mpstag reference internal" href="#design.mps.collection.scan-fix">.scan-fix:</a> “Scanning” an object means applying the “fix”
|
|
function to all references in that object. Fixing is the generic name
|
|
for the operation that takes a reference to a white object and makes
|
|
it non-white (usually grey, but black is a possibility, and so is
|
|
changing the reference as we do for weak references). Typical examples
|
|
of fix methods are copying the object into to-space or setting its
|
|
mark bit.</p>
|
|
<p><span class="target" id="design.mps.collection.cooperation"></span><a class="mpstag reference internal" href="#design.mps.collection.cooperation">.cooperation:</a> The separation of scanning and fixing is what
|
|
allows different GC techniques to cooperate. The scanning is done by a
|
|
method on the pool that the scanned object resides in, and the fixing
|
|
is done by a method on the pool that the reference points to.</p>
|
|
<p><span class="target" id="design.mps.collection.scan-all"></span><a class="mpstag reference internal" href="#design.mps.collection.scan-all">.scan-all:</a> Pools provide a method to scan all the grey
|
|
objects in a segment.</p>
|
|
</div>
|
|
<div class="section" id="reference-sets">
|
|
<h3>6.4.2. Reference sets<a class="headerlink" href="#reference-sets" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.refsets"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets">.refsets:</a> The cost of scanning can be significantly reduced
|
|
by storing remembered sets. We have chosen a very compact and
|
|
efficient implementation, called reference sets, or refsets for short
|
|
(see idea.remember [design.mps.refset is empty!
|
|
Perhaps some of this should go there. – Pekka 1998-02-19]). This
|
|
makes the cost of maintaining them low, so we maintain them for all
|
|
references out of all scannable segments.</p>
|
|
<p><span class="target" id="design.mps.collection.refsets.approx"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets.approx">.refsets.approx:</a> You might describe refsets as summaries of
|
|
all references out of an area of memory, so they are only
|
|
approximations of remembered sets. When a refset indicates that an
|
|
interesting reference might be present in a segment, we still have to
|
|
scan the segment to find it.</p>
|
|
<p><span class="target" id="design.mps.collection.refsets.scan"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets.scan">.refsets.scan:</a> The refset information is collected during
|
|
scanning. The scan state protocol provides a way for the pool and the
|
|
format scan methods to cooperate in this, and to pass this information
|
|
to the tracer module which checks it and updates the segment (see
|
|
design.mps.scan [Actually, there’s very little doc there.
|
|
Pekka 1998-02-17]).</p>
|
|
<p><span class="target" id="design.mps.collection.refsets.maintain"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets.maintain">.refsets.maintain:</a> The MPS tries to maintain the refset
|
|
information when it moves or changes object.</p>
|
|
<p><span class="target" id="design.mps.collection.refsets.pollution"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets.pollution">.refsets.pollution:</a> Ambiguous references and pointers outside
|
|
the arena will introduce spurious zones into the refsets. We put up
|
|
with this to keep the scanning costs down. Consistency checks on
|
|
refsets have to take this into account.</p>
|
|
<p><span class="target" id="design.mps.collection.refsets.write-barrier"></span><a class="mpstag reference internal" href="#design.mps.collection.refsets.write-barrier">.refsets.write-barrier:</a> A write-barrier are needed to keep
|
|
the mutator from invalidating the refsets when writing to a segment.
|
|
We need one on any scannable segment whose refset is not a superset of
|
|
the mutator’s (and that the mutator can see). If we know what the
|
|
mutator is writing and whether it’s a reference, we can just add that
|
|
reference to the refset (figuring out whether anything can be removed
|
|
from the refset is too expensive). If we don’t know or if we cannot
|
|
afford to keep the barrier up, the framework can union the mutator’s
|
|
refset to the segment’s refset.</p>
|
|
<p><span class="target" id="design.mps.collection.refset.mutator"></span><a class="mpstag reference internal" href="#design.mps.collection.refset.mutator">.refset.mutator:</a> The mutator’s refset could be computed
|
|
during root scanning in the usual way, and then kept up to date by
|
|
using a read-barrier. It’s not a problem that the mutator can create
|
|
new pointers out of nothing behind the read-barrier, as they won’t be
|
|
real references. However, this is probably not cost-effective, since
|
|
it would cause lots of barrier hits. We’d need a read-barrier on every
|
|
scannable segment whose refset is not a subset of the mutator’s (and
|
|
that the mutator can see). So instead we approximate the mutator’s
|
|
refset with the universal refset.</p>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="the-tracer">
|
|
<h2>6.5. The tracer<a class="headerlink" href="#the-tracer" title="Permalink to this headline">¶</a></h2>
|
|
<p><span class="target" id="design.mps.collection.tracer"></span><a class="mpstag reference internal" href="#design.mps.collection.tracer">.tracer:</a> The tracer is an engine for implementing multiple
|
|
garbage collection processes. Each process (called a “trace”) proceeds
|
|
independently of the others through five phases as described in
|
|
analysis.tracer. The following sections describe how the action of
|
|
each phase fits into the framework. See design.mps.trace
|
|
for details [No, there’s not much there, either. Possibly some of this
|
|
section should go there. Pekka 1998-02-18]).</p>
|
|
<p><span class="target" id="design.mps.collection.combine"></span><a class="mpstag reference internal" href="#design.mps.collection.combine">.combine:</a> The tracer can also combine several traces for some
|
|
actions, like scanning a segment or a root. The methods the tracer
|
|
calls to do the work get an argument that tells them which traces they
|
|
are expected to act for. [extend this@@@@]</p>
|
|
<p><span class="target" id="design.mps.collection.trace.begin"></span><a class="mpstag reference internal" href="#design.mps.collection.trace.begin">.trace.begin:</a> Traces are started by external request, usually
|
|
from a client function or an action (see design.mps.action).</p>
|
|
<p><span class="target" id="design.mps.collection.trace.progress"></span><a class="mpstag reference internal" href="#design.mps.collection.trace.progress">.trace.progress:</a> The tracer gets time slices from the arena
|
|
to work on a given trace [This is just a provisional arrangement, in
|
|
lieu of real progress control. Pekka 1998-02-18]. In each slice, it
|
|
selects a small amount of work to do, based on the state of the trace,
|
|
and does it, using facilities provided by the pools. .trace.scan: A
|
|
typical unit of work is to scan a single segment. The tracer can
|
|
choose to do this for multiple traces at once, provided the segment is
|
|
grey for more than one trace.</p>
|
|
<p><span class="target" id="design.mps.collection.trace.barrier"></span><a class="mpstag reference internal" href="#design.mps.collection.trace.barrier">.trace.barrier:</a> Barrier hits might also cause a need to scan
|
|
:mps:a segment (see ref:<cite>.hw-barriers.hit</cite>). Again, the tracer can
|
|
:mps:choose to combine traces, when it does this.</p>
|
|
<p><span class="target" id="design.mps.collection.mutator-colour"></span><a class="mpstag reference internal" href="#design.mps.collection.mutator-colour">.mutator-colour:</a> The framework keeps track of the colour of
|
|
the mutator separately for each trace.</p>
|
|
<div class="section" id="the-condemn-phase">
|
|
<h3>6.5.1. The condemn phase<a class="headerlink" href="#the-condemn-phase" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.phase.condemn"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.condemn">.phase.condemn:</a> The agent that creates the trace (see
|
|
<a class="reference internal" href="#design.mps.collection.trace.begin">.trace.begin</a>) determines the condemned set and colours it
|
|
white. The tracer then examines the refsets on all scannable segments,
|
|
and if it can deduce some segment cannot refer to the white set, it’s
|
|
immediately coloured black, otherwise the pool is asked to grey any
|
|
objects in the segment that might need to be scanned (in copying
|
|
pools, this is typically the whole segment).</p>
|
|
<p><span class="target" id="design.mps.collection.phase.condemn.zones"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.condemn.zones">.phase.condemn.zones:</a> To get the maximum benefit from the
|
|
refsets, we try to arrange that the zones are a minimal superset (for
|
|
example, generations uniquely occupy zones) and a maximal subset
|
|
(there’s nothing else in the zone) of the condemned set. This needs to
|
|
be arranged at allocation time (or when copying during collection,
|
|
which is much like allocation) [soon, this will be handled by segment
|
|
loci, see design.mps.locus].</p>
|
|
<p><span class="target" id="design.mps.collection.phase.condemn.mutator"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.condemn.mutator">.phase.condemn.mutator:</a> At this point, the mutator might
|
|
reference any objects, that is, it is grey. Allocation can be in any
|
|
colour, most commonly white [more could be said about this].</p>
|
|
</div>
|
|
<div class="section" id="the-grey-mutator-phase">
|
|
<h3>6.5.2. The grey mutator phase<a class="headerlink" href="#the-grey-mutator-phase" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.phase.grey-mutator"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.grey-mutator">.phase.grey-mutator:</a> Grey segments are chosen according to
|
|
some sort of progress control and scanned by the pool to make them
|
|
black. Eventually, the tracer will decide to flip or it runs out of
|
|
grey segments, and proceeds to the next phase. [Currently, this phase
|
|
has not been implemented; all traces flip immediately after condemn.
|
|
Pekka 1998-02-18]</p>
|
|
<p><span class="target" id="design.mps.collection.phase.grey-mutator.copy"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.grey-mutator.copy">.phase.grey-mutator.copy:</a> At this stage, we don’t want to
|
|
copy condemned objects, because we would need an additional barrier to
|
|
keep the mutator’s view of the heap consistent (see
|
|
analysis.async-gc.copied.pointers-and-new-copy).</p>
|
|
<p><span class="target" id="design.mps.collection.phase.grey-mutator.ambig"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.grey-mutator.ambig">.phase.grey-mutator.ambig:</a> This is a good time to get all
|
|
ambiguous scanning out of the way, because we usually can’t do any
|
|
after the flip [write a detailed explanation of this some day] and
|
|
because it doesn’t cause any copying.</p>
|
|
</div>
|
|
<div class="section" id="the-flip-phase">
|
|
<h3>6.5.3. The flip phase<a class="headerlink" href="#the-flip-phase" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.phase.flip"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.flip">.phase.flip:</a> The roots (see design.mps.root) are
|
|
scanned. This has to be an atomic action as far as the mutator is
|
|
concerned, so all threads are suspended for the duration.</p>
|
|
<p><span class="target" id="design.mps.collection.phase.flip.mutator"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.flip.mutator">.phase.flip.mutator:</a> After this, the mutator is black: if we
|
|
use a strong barrier (analysis.async-gc.strong), this means
|
|
it cannot refer to white objects. Allocation will be in black (could
|
|
be grey as well, but there’s no point to it).</p>
|
|
</div>
|
|
<div class="section" id="the-black-mutator-phase">
|
|
<h3>6.5.4. The black mutator phase<a class="headerlink" href="#the-black-mutator-phase" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.phase.black-mutator"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.black-mutator">.phase.black-mutator:</a> Grey segments are chosen according to
|
|
some sort of progress control and scanned by the pool to make them
|
|
black. Eventually, the tracer runs out of segments that are grey for
|
|
this trace, and proceeds to the next phase.</p>
|
|
<p><span class="target" id="design.mps.collection.phase.black-mutator.copy"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.black-mutator.copy">.phase.black-mutator.copy:</a> At this stage white objects can be
|
|
relocated, because the mutator cannot see them (as long as a strong
|
|
barrier is used, as we must do for a copying collection, see
|
|
analysis.async-gc.copied.pointers).</p>
|
|
</div>
|
|
<div class="section" id="the-reclaim-phase">
|
|
<h3>6.5.5. The reclaim phase<a class="headerlink" href="#the-reclaim-phase" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.phase.reclaim"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.reclaim">.phase.reclaim:</a> The tracer finds the remaining white segments
|
|
and asks the pool to reclaim any white objects in them.</p>
|
|
<p><span class="target" id="design.mps.collection.phase.reclaim.barrier"></span><a class="mpstag reference internal" href="#design.mps.collection.phase.reclaim.barrier">.phase.reclaim.barrier:</a> Once a trace has started reclaiming
|
|
objects, the others shouldn’t try to scan any objects that are white
|
|
for it, because they might have dangling pointers in them [xref doc
|
|
yet to be written]. [Currently, we reclaim atomically, but it could be
|
|
incremental, or even overlapped with a new trace on the same condemned
|
|
set. Pekka 1997-12-31]</p>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="barriers">
|
|
<h2>6.6. Barriers<a class="headerlink" href="#barriers" title="Permalink to this headline">¶</a></h2>
|
|
<p>[An introduction and a discussion of general principles should go
|
|
here. This is a completely undesigned area.]</p>
|
|
<div class="section" id="hardware-barriers">
|
|
<h3>6.6.1. Hardware barriers<a class="headerlink" href="#hardware-barriers" title="Permalink to this headline">¶</a></h3>
|
|
<p><span class="target" id="design.mps.collection.hw-barriers"></span><a class="mpstag reference internal" href="#design.mps.collection.hw-barriers">.hw-barriers:</a> Hardware barrier services cannot, by their very
|
|
nature, be independently provided to each trace. A segment is either
|
|
protected or not, and we have to set the protection on a segment if
|
|
any trace needs a hardware barrier on it.</p>
|
|
<p><span class="target" id="design.mps.collection.hw-barriers.supported"></span><a class="mpstag reference internal" href="#design.mps.collection.hw-barriers.supported">.hw-barriers.supported:</a> The framework currently supports
|
|
segment-oriented Appel-Ellis-Li barriers
|
|
(analysis.async-gc.barrier.appel-ellis-li), and
|
|
write-barriers for keeping the refsets up-to-date. It would not be
|
|
hard to add Steele barriers
|
|
(analysis.async-gc.barrier.steele.scalable).</p>
|
|
<p><span class="target" id="design.mps.collection.hw-barriers.hit"></span><a class="mpstag reference internal" href="#design.mps.collection.hw-barriers.hit">.hw-barriers.hit:</a> When a barrier hit happens, the arena
|
|
determines which segment it was on. The segment colour info is used to
|
|
determine whether it had trace barriers on it, and if so, the
|
|
appropriate barrier action is performed, using the methods of the
|
|
owning pool. If the segment was write-protected, its refset is unioned
|
|
with the refset of the mutator [in practice, <tt class="xref c c-macro docutils literal"><span class="pre">RefSetUNIV</span></tt>].</p>
|
|
<p><span class="target" id="design.mps.collection.hw-barriers.hit.multiple"></span><a class="mpstag reference internal" href="#design.mps.collection.hw-barriers.hit.multiple">.hw-barriers.hit.multiple:</a> Fortunately, if we get a barrier
|
|
hit on a segment with multiple trace barriers on it, we can scan it
|
|
for all the traces that it had a barrier for, see .combine.@@@@</p>
|
|
</div>
|
|
<div class="section" id="software-barriers">
|
|
<h3>6.6.2. Software barriers<a class="headerlink" href="#software-barriers" title="Permalink to this headline">¶</a></h3>
|
|
<p>[@@@@Have to say something about software barriers]</p>
|
|
</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="#">6. Collection framework</a><ul>
|
|
<li><a class="reference internal" href="#introduction">6.1. Introduction</a></li>
|
|
<li><a class="reference internal" href="#history">6.2. History</a></li>
|
|
<li><a class="reference internal" href="#overview">6.3. Overview</a></li>
|
|
<li><a class="reference internal" href="#collection-abstractions">6.4. Collection abstractions</a><ul>
|
|
<li><a class="reference internal" href="#colours-scanning-and-fixing">6.4.1. Colours, scanning and fixing</a></li>
|
|
<li><a class="reference internal" href="#reference-sets">6.4.2. Reference sets</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a class="reference internal" href="#the-tracer">6.5. The tracer</a><ul>
|
|
<li><a class="reference internal" href="#the-condemn-phase">6.5.1. The condemn phase</a></li>
|
|
<li><a class="reference internal" href="#the-grey-mutator-phase">6.5.2. The grey mutator phase</a></li>
|
|
<li><a class="reference internal" href="#the-flip-phase">6.5.3. The flip phase</a></li>
|
|
<li><a class="reference internal" href="#the-black-mutator-phase">6.5.4. The black mutator phase</a></li>
|
|
<li><a class="reference internal" href="#the-reclaim-phase">6.5.5. The reclaim phase</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a class="reference internal" href="#barriers">6.6. Barriers</a><ul>
|
|
<li><a class="reference internal" href="#hardware-barriers">6.6.1. Hardware barriers</a></li>
|
|
<li><a class="reference internal" href="#software-barriers">6.6.2. Software barriers</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h4>Previous topic</h4>
|
|
<p class="topless"><a href="class-interface.html"
|
|
title="previous chapter">5. Pool class interface</a></p>
|
|
<h4>Next topic</h4>
|
|
<p class="topless"><a href="config.html"
|
|
title="next chapter">7. Configuration</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="config.html" title="7. Configuration"
|
|
>next</a> |</li>
|
|
<li class="right" >
|
|
<a href="class-interface.html" title="5. Pool class interface"
|
|
>previous</a> |</li>
|
|
<li><a href="../index.html">Memory Pool System 1.111.0 documentation</a> »</li>
|
|
<li><a href="index.html" >Design</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> |