/usr/share/doc/sbcl/sbcl-internals/Heap-Object-Layout.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- This manual is part of the SBCL software system. See the
README file for more information.

This manual is in the public domain and is provided with absolutely no
warranty. See the COPYING and CREDITS files for more
information. -->
<!-- Created by GNU Texinfo 6.5, http://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Heap Object Layout (SBCL Internals)</title>

<meta name="description" content="Heap Object Layout (SBCL Internals)">
<meta name="keywords" content="Heap Object Layout (SBCL Internals)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<link href="index.html#Top" rel="start" title="Top">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Objects-In-Memory.html#Objects-In-Memory" rel="up" title="Objects In Memory">
<link href="Signal-handling.html#Signal-handling" rel="next" title="Signal handling">
<link href="Type-tags.html#Type-tags" rel="prev" title="Type tags">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en">
<a name="Heap-Object-Layout"></a>
<div class="header">
<p>
Previous: <a href="Type-tags.html#Type-tags" accesskey="p" rel="prev">Type tags</a>, Up: <a href="Objects-In-Memory.html#Objects-In-Memory" accesskey="u" rel="up">Objects In Memory</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
</div>
<hr>
<a name="Heap-Object-Layout-1"></a>
<h3 class="section">6.2 Heap Object Layout</h3>

<p>Objects stored in the heap are of two kinds: those with headers, and
cons cells.  If the first word of an object has a header widetag then
the object has the type and layout associated with that widetag.
Otherwise, the object is assumed to be a <code>cons</code> cell.
</p>
<p>Some objects have &ldquo;unboxed&rdquo; words without any associated type
information as well as the more usual &ldquo;boxed&rdquo; words with lowtags.
Obvious cases include the specialized array types, some of the numeric
types, <code>system-area-pointer</code>s, and so on.
</p>
<p>The primitive object layouts are specified in
<samp>src/compiler/generic/objdef.lisp</samp>.
</p>
<a name="Header-Values"></a>
<h4 class="subsection">6.2.1 Header Values</h4>

<p>As a widetag is only eight bits wide but a heap object header takes a
full machine word, there is an extra 24 or 56 bits of space available
for unboxed data storage in each heap object.  This space is called
the &ldquo;header value&rdquo;, and is used for various purposes depending on
the type of heap object in question.
</p>
<a name="Symbols"></a>
<h4 class="subsection">6.2.2 Symbols</h4>

<p>In contrast to the simple model of symbols provided in the Common Lisp
standard, symbol objects in SBCL do not have a function cell.
Instead, the mapping from symbols to functions is done via the
compiler globaldb.
</p>
<p>There are two additional slots associated with symbols.  One is a hash
value for the symbol (based on the symbol name), which avoids having
to recompute the hash from the name every time it is required.
</p>
<p>The other additional slot, on threaded systems only, is the TLS index,
which is either <code>no-tls-value-marker-widetag</code> or an unboxed byte
offset within the TLS area to the TLS slot associated with the symbol.
Because the unboxed offset is aligned to a word boundary it appears as
a <code>fixnum</code> when viewed as boxed data.  It is not, in general,
safe to increment this value as a <code>fixnum</code>, however, in case
<code>n-fixnum-tag-bits</code> changes<a name="DOCF8" href="#FOOT8"><sup>8</sup></a>.
</p>
<a name="The-NIL_002dcons-Hack"></a>
<h4 class="subsection">6.2.3 The NIL-cons Hack</h4>

<p>As an &ldquo;optimization&rdquo;, the symbol <code>nil</code> has
<code>list-pointer-lowtag</code> rather than <code>other-pointer-lowtag</code>,
and is aligned in memory so that the value and hash slots are the
<code>car</code> and <code>cdr</code> of the <code>cons</code>, with both slots
containing <code>nil</code>.  This allows for <code>car</code> and <code>cdr</code> to
simply do a lowtag test and slot access instead of having to
explicitly test for <code>nil</code>, at the cost of requiring all symbol
type tests and slot accesses to test for <code>nil</code>.
</p>
<a name="Functions-and-Code-Components"></a>
<h4 class="subsection">6.2.4 Functions and Code Components</h4>


<p>All compiled code resides in <code>code-component</code> objects.  These
objects consist of a header, some number of boxed literal values, a
&ldquo;data block&rdquo; containing machine code and <code>simple-fun</code> headers,
and a &ldquo;trace table&rdquo; which is currently unused<a name="DOCF9" href="#FOOT9"><sup>9</sup></a>.
</p>
<p>The <code>simple-fun</code> headers represent simple function objects (not
<code>funcallable-instance</code>s or closures), and each
<code>code-component</code> will typically have one for the main entry point
and one per closure entry point (as the function underlying the
closure, not the closure object proper).  In a compiler trace-file,
the <code>simple-fun</code> headers are all listed as entries in the IR2
component.
</p>
<p>The <code>simple-fun</code> headers are held in a linked list per
<code>code-component</code> in order to allow the garbage collector to find
them during relocation.  In order to be able to find the start of a
<code>code-component</code> from a <code>simple-fun</code>, the header value is
the offset in words from the start of the <code>code-component</code> to the
start of the <code>simple-fun</code>.
</p><div class="footnote">
<hr>
<h4 class="footnotes-heading">Footnotes</h4>

<h3><a name="FOOT8" href="#DOCF8">(8)</a></h3>
<p>This is not as unlikely as
it might seem at first; while historically <code>n-fixnum-tag-bits</code>
has always been the same as <code>word-shift</code> there is a branch where
it is permitted to vary at build time from <code>word-shift</code> to as low
as 1 on 64-bit ports, and a proposed scheme to allow the same on
32-bit ports</p>
<h3><a name="FOOT9" href="#DOCF9">(9)</a></h3>
<p>Trace tables
were originally used to support garbage collection using gengc in
CMUCL.  As there is still vestigial support for carrying them around
at the end of <code>code-component</code>s, they may end up being used for
something else in the future.</p>
</div>
<hr>
<div class="header">
<p>
Previous: <a href="Type-tags.html#Type-tags" accesskey="p" rel="prev">Type tags</a>, Up: <a href="Objects-In-Memory.html#Objects-In-Memory" accesskey="u" rel="up">Objects In Memory</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
</div>



</body>
</html>
sbcl-doc 2:1.4.5-1 / usr / share / doc / sbcl / sbcl-internals / Heap-Object-Layout.html
