mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-01-05 11:21:04 -08:00
326 lines
14 KiB
HTML
326 lines
14 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
|
|
<head>
|
|
|
|
<title>Tracer</title>
|
|
|
|
</head>
|
|
|
|
<body bgcolor="#FFFFFF" text="#000000" link="#000099" vlink="#660066" alink="#FF0000">
|
|
|
|
<div align="center">
|
|
|
|
<p>
|
|
<a href="/">Ravenbrook</a> /
|
|
<a href="/project/">Projects</a> /
|
|
<a href="/project/mps/">Memory Pool System</a> /
|
|
<a href="/project/mps/master/">Master Product Sources</a> /
|
|
<a href="/project/mps/master/design/">Design Documents</a>
|
|
</p>
|
|
|
|
<p><i><a href="/project/mps/">Memory Pool System Project</a></i></p>
|
|
|
|
<hr />
|
|
|
|
</div>
|
|
|
|
<h2>Status</h2>
|
|
|
|
<p>This document is currently a mixture of very old design notes (the
|
|
preformatted section immediately following) and some newer stuff. It
|
|
doesn't yet form anything like a complete picture.
|
|
</p>
|
|
|
|
<pre>
|
|
TRACER
|
|
design.mps.trace
|
|
incomplete design
|
|
drj 1996-09-25
|
|
|
|
|
|
ARCHITECTURE:
|
|
|
|
<a id="instance.limit" name="instance.limit">.instance.limit</a>: There will be a limit on the number of traces that can be
|
|
created at any one time. This effectively limits the number of concurrent
|
|
traces. This limitation is expressed in the symbol TRACE_MAX [currently set to
|
|
1, see request.mps.160020 "Multiple traces would not work" drj 1998-06-15].
|
|
|
|
<a id="rate" name="rate">.rate</a>: [see mail.nickb.1997-07-31.14-37]. [Now revised? See
|
|
request.epcore.160062 and change.epcore.minnow.160062. drj 1998-06-15]
|
|
|
|
<a id="exact.legal" name="exact.legal">.exact.legal</a>: Exact references should either point outside the arena (to
|
|
non-managed address space) or to a tract allocated to a pool. Exact references
|
|
that are to addresses which the arena has reserved but hasn't allocated memory
|
|
to are illegal (the exact reference couldn't possibly refer to a real object).
|
|
Depending on the future semantics of PoolDestroy we might need to adjust our
|
|
strategy here. See mail.dsm.1996-02-14.18-18 for a strategy of coping
|
|
gracefully with PoolDestroy. We check that this is the case in the fixer. It
|
|
may be sensible to make this check CRITICAL in certain configurations.
|
|
|
|
<a id="fix.fixed.all" name="fix.fixed.all">.fix.fixed.all</a>: ss->fixedSummary is accumulated (in the fixer) for all the
|
|
pointers whether or not they are genuine references. We could accumulate fewer
|
|
pointers here; if a pointer fails the TractOfAddr test then we know it isn't a
|
|
reference, so we needn't accumulate it into the fixed summary. The design
|
|
allows this, but it breaks a useful post-condition on scanning (if the
|
|
accumulation of ss->fixedSummary was moved the accuracy of ss->fixedSummary
|
|
would vary according to the "width" of the white summary). See
|
|
mail.pekka.1998-02-04.16-48 for improvement suggestions.
|
|
|
|
|
|
ANALYSIS:
|
|
|
|
<a id="fix.copy-fail" name="fix.copy-fail">.fix.copy-fail</a>: Fixing can always succeed, even if copying the referenced
|
|
object has failed (due to lack of memory, for example), by backing off to
|
|
treating a reference as ambiguous. Assuming that fixing an ambiguous reference
|
|
doesn't allocate memory (which is no longer true for AMC for example). See
|
|
request.dylan.170560 for a slightly more sophisticated way to proceed when you
|
|
can no longer allocate memory for copying.
|
|
|
|
|
|
IDEAS:
|
|
|
|
<a id="flip.after" name="flip.after">.flip.after</a>: To avoid excessive barrier impact on the mutator immediately after
|
|
flip, we could scan during flip other objects which are "near" the roots, or
|
|
otherwise known to be likely to be accessed in the near future.
|
|
|
|
|
|
IMPLEMENTATION:
|
|
|
|
Speed
|
|
|
|
<a id="fix" name="fix">.fix</a>: The fix path is critical to garbage collection speed. Abstractly fix is
|
|
applied to all the references in the non-white heap and all the references in
|
|
the copied heap. Remembered sets cut down the number of segments we have to
|
|
scan. The zone test cuts down the number of references we call fix on. The
|
|
speed of the remainder of the fix path is still critical to system
|
|
performance. Various modifications to and aspects of the system are concerned
|
|
with maintaining the speed along this path.
|
|
|
|
<a id="fix.tractofaddr" name="fix.tractofaddr">.fix.tractofaddr</a>: TractOfAddr is called on every reference that passes the zone
|
|
test and is on the critical path, to determine whether the segment is white.
|
|
There is no need to examine the segment to perform this test, since whiteness
|
|
information is duplicated in tracts, specifically to optimize this test.
|
|
TractOfAddr itself is a simple class dispatch function (which dispatches to the
|
|
arena class's TractOfAddr method). Inlining the dispatch and inlining the
|
|
functions called by VMTractOfAddr makes a small but noticable difference to the
|
|
speed of the dylan compiler.
|
|
|
|
<a id="fix.noaver" name="fix.noaver">.fix.noaver</a>: AVERs in the code add bulk to the code (reducing I-cache efficacy)
|
|
and add branches to the path (polluting the branch pedictors) resulting in a
|
|
slow down. Removing all the AVERs from the fix path improves the overall speed
|
|
of the dylan compiler by as much as 9%.
|
|
|
|
<a id="fix.nocopy" name="fix.nocopy">.fix.nocopy</a>: AMCFix used to copy objects by using the format's copy method.
|
|
This involved a function call (through an indirection) and in dylan_copy a call
|
|
to dylan_skip (to recompute the length) and call to memcpy with general
|
|
parameters. Replacing this with a direct call to memcpy removes these
|
|
overheads and the call to memcpy now has aligned parameters. The call to
|
|
memcpy is inlined by the (C) compiler. This change results in a 4-5% speed-up
|
|
in the dylan compiler.
|
|
|
|
<a id="reclaim" name="reclaim">.reclaim</a>: Because the reclaim phase of the trace (implemented by TraceReclaim)
|
|
examines every segment it is fairly time intensive. rit's profiles presented
|
|
in request.dylan.170551 show a gap between the two varieties variety.hi and
|
|
variety.wi.
|
|
|
|
<a id="reclaim.noaver" name="reclaim.noaver">.reclaim.noaver</a>: Converting AVERs in the loops of TraceReclaim, PoolReclaim,
|
|
AMCReclaim (LOReclaim? AWLReclaim) will result in a noticeable speed
|
|
improvement [insert actual speed improvement here].
|
|
|
|
</pre>
|
|
|
|
<h2>Life cycle of a trace object</h2>
|
|
|
|
<p> TraceCreate creates a trace in state TraceINIT </p>
|
|
|
|
<p> Some segments get condemned (made white). </p>
|
|
|
|
<p> TraceStart gets called which: </p>
|
|
|
|
<ul>
|
|
|
|
<li> <p> Derives an initial reference partition based on the existing
|
|
white set. The white zone set and the segments' summaries are used to
|
|
create an initial grey set. </p> </li>
|
|
|
|
<li> <p> emits a GCStart message. </p> </li>
|
|
|
|
<li> <p> initialises trace->rate by estimating the required scanning
|
|
rate </p> </li>
|
|
|
|
<li> <p> moves the trace into the state TraceUNFLIPPED </p> </li>
|
|
|
|
<li> <p> immediately calls traceFlip which flips the trace and moves
|
|
it into state TraceFLIPPED. </p> </li>
|
|
|
|
</ul>
|
|
|
|
<p>Whilst a trace is alive every so often its
|
|
<code>traceQuantum</code> method gets invoked (via
|
|
<code>TracePoll</code>) in order to do a quantum of tracing work.
|
|
<code>traceQuantum</code> is responsible for ticking through the trace's
|
|
top-level state machine. Most of the interesting work, the tracing,
|
|
happens in the <code>TraceFLIPPED</code> state. </p>
|
|
|
|
<p>The trace transitions through its states in the following sequence:
|
|
<code>TraceINIT</code> ->
|
|
(<code>TraceUNFLIPPED</code>) -> <code>TraceFLIPPED</code> ->
|
|
<code>TraceRECLAIM</code> -> <code>TraceFINISHED</code>.</p>
|
|
|
|
<p>Whilst <code>TraceUNFLIPPED</code> appears in the code, no trace does
|
|
any work in this state; all traces are immediately flipped to be in the
|
|
<code>TraceFLIPPED</code> state (see above).</p>
|
|
|
|
<p>Once the trace is in the <code>TraceFINISHED</code> state it performs
|
|
no more work and it can be safely destroyed. Generally the callers of
|
|
<code>traceQuantum</code> will destroy the trace.</p>
|
|
|
|
<h2>Making Progress - Scanning Grey Segments</h2>
|
|
|
|
<p>Most of the interesting work of a trace, the actual tracing, happens
|
|
in the <code>TraceFLIPPED</code> state (work <em>would</em> happen in
|
|
the <code>TraceUNFLIPPED</code> state, but that is not implemented).</p>
|
|
|
|
<p>The tracer makes progress by choosing a grey segment to scan, and
|
|
scanning it. The actual scanning is performed by pools.</p>
|
|
|
|
<p>Note that at all times a reference partition is maintained.</p>
|
|
|
|
<p>The order in which the trace scans things determines the semantics of
|
|
certain types of references (in particular, weak and final references).
|
|
Or, to put it another way the desired semantics of weak and final
|
|
references impose certain restrictions on the order in which the trace
|
|
can scan things.</p>
|
|
|
|
<p>The tracer uses a system of <em>reference ranks</em> (or just
|
|
ranks) so that it can impose an order on its scanning work. The ranks
|
|
are ordered.</p>
|
|
|
|
<p>The tracer proceeds band by band. The first band is all objects it
|
|
can reach by following references of the first rank. The second band is
|
|
all subsequent objects it can reach by following references of the
|
|
second and first ranks. The third band is all subsequent objects it can
|
|
reach by following references of the third, second, and first ranks.
|
|
And so on. The description of the tracer working like this originated
|
|
in an e-mail message from RHSK [<a href="#RHSK-2007-06-25">RHSK
|
|
2007-06-25</a>].</p>
|
|
|
|
<p>A trace keep track of which band it is tracing. This is returned by
|
|
the <code>TraceBand</code> method. Keeping this band information helps
|
|
it implement the semantics of finalization and weakness. The band used
|
|
to not be explicitly stored, but this hindered the implementation of
|
|
good finalization semantics (essentially in some circumstances
|
|
finalization messages were delayed by at least one collection cycle, see
|
|
<a href="http://info.ravenbrook.com/project/mps/issue/job001658/">job001658</a>).</p>
|
|
|
|
<p>The band is used when selecting a grey segment to scan (the selection
|
|
occurs in <code>traceFindGrey</code>). The tracer attempts to first
|
|
find segments whose rank is the current band, then segments whose rank
|
|
is previous to the current band, and so on. If there are no segments
|
|
found then the current band is exhausted and the current band is
|
|
incremented to the next rank. When the current band is moved through
|
|
all the ranks in this fashion there is no more tracing to be done.
|
|
</p>
|
|
|
|
|
|
<h2><a id="section-A" name="section-A">A. References</a></h2>
|
|
|
|
|
|
<table>
|
|
|
|
<!-- Template Entry
|
|
|
|
<tr valign="top">
|
|
|
|
<td>[<a id="ref-#REF#" name="ref-#REF#" href="#REF_URL#">#REF_NAME#</a>]</td>
|
|
|
|
<td>
|
|
"#REF_TITLE#";
|
|
#REF_AUTHOR#;
|
|
<URL: <a href="#REF_URL#">#REF_URL#</a>>;
|
|
#REF_DATE#.
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
-->
|
|
|
|
<tr valign="top">
|
|
<td>[<a id="ref-RHSK-2007-06-25">RHSK 2007-06-25</a>]</td>
|
|
|
|
<td>"the semantics of rank-based tracing";
|
|
<a href="mailto:rhsk@ravenbrook.com">RHSK</a>;
|
|
<URL: <a
|
|
href="http://info.ravenbrook.com/mail/2007/06/25/11-35-57/0.txt">http://info.ravenbrook.com/mail/2007/06/25/11-35-57/0.txt</a>>;
|
|
2007-06-25.
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
<h2><a id="section-B" name="section-B">B. Document History</a></h2>
|
|
|
|
<table>
|
|
|
|
<tr valign="top">
|
|
|
|
<td>2002-06-07</td>
|
|
|
|
<td><a href="mailto:rb@ravenbrook.com">RB</a></td>
|
|
|
|
<td>Converted from MMInfo database design document.</td>
|
|
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td>2007-07-02</td>
|
|
<td><a href="mailto:drj@ravenbrook.com">DRJ</a></td>
|
|
<td>Added notes on tracer progress</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
<h2><a id="section-C" name="section-C">C. Copyright and License</a></h2>
|
|
|
|
<p> This document is copyright © 1995-2002 <a href="http://www.ravenbrook.com/">Ravenbrook Limited</a>. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options. </p>
|
|
|
|
<p> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: </p>
|
|
|
|
<ol>
|
|
|
|
<li> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. </li>
|
|
|
|
<li> Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. </li>
|
|
|
|
<li> Redistributions in any form must be accompanied by information on how to obtain complete source code for the this software and any accompanying software that uses this software. The source code must either be included in the distribution or be available for no more than the cost of distribution plus a nominal fee, and must be freely redistributable under reasonable conditions. For an executable file, complete source code means the source code for all modules it contains. It does not include source code for modules or files that typically accompany the major components of the operating system on which the executable file runs. </li>
|
|
|
|
</ol>
|
|
|
|
<p> <strong> This software is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage. </strong> </p>
|
|
|
|
|
|
<hr />
|
|
|
|
<div align="center">
|
|
|
|
<p><code>$Id$</code></p>
|
|
|
|
<p>
|
|
<a href="/">Ravenbrook</a> /
|
|
<a href="/project/">Projects</a> /
|
|
<a href="/project/mps/">Memory Pool System</a> /
|
|
<a href="/project/mps/master/">Master Product Sources</a> /
|
|
<a href="/project/mps/master/design/">Design Documents</a>
|
|
</p>
|
|
|
|
</div>
|
|
|
|
</body>
|
|
|
|
</html>
|