Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

[389e37]: impnotes / memory-models.html Maximize Restore History

Download this file

memory-models.html    80 lines (79 with data), 16.4 kB

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!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>35.4. Memory Models</title><link rel="stylesheet" type="text/css" href="impnotes.css" /><link rev="made" href="mailto:clisp-list@lists.sourceforge.net" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot_8706" /><link rel="home" href="index.html" title="Implementation Notes for GNU CLISP" /><link rel="up" href="gc.html" title="Chapter 35. Overview of CLISP's Garbage Collection" /><link rel="prev" href="typecodes.html" title="35.3. Object Pointer Representations" /><link rel="next" href="gc-safety.html" title="35.5. The burden of garbage-collection upon the rest of CLISP" /><link rel="copyright" href="legalese.html" title="Legal Status of the CLISP Implementation Notes" /><meta name="date" content="'generated: 2010-07-07 11:48:49-04:00'" /><link rel="author" title="Authors" href="index.html#authors" /><link rel="contents" title="Table of Contents" href="index.html" /><link rel="glossary" href="glossary.html" /><link rel="help" href="faq.html#faq-help" title="How do I ask for help?" /><link rel="home" title="Home" href="http://clisp.cons.org" /><link rel="index" href="idx.html" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">35.4. Memory Models</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="typecodes.html">Prev</a> </td><th width="60%" align="center">Chapter 35. Overview of <span class="command"><strong>CLISP</strong></span>'s Garbage Collection</th><td width="20%" align="right"> <a accesskey="n" href="gc-safety.html">Next</a></td></tr></table><hr /></div><div class="section" title="35.4. Memory Models"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="memory-models"></a>35.4. Memory Models</h2></div></div></div><p>There are 6 memory models. Which one is used, depends on the
operating system and is determined at build time.</p><div class="variablelist" title="Memory Models"><p class="title">Memory Models</p><dl><dt><span class="term">SPVW_MIXED_BLOCKS_OPPOSITE</span></dt><dd><p>The heap consists of one block of fixed length
(allocated at startup).
The variable-length objects are allocated from the left, the 2-pointer
objects are allocated from the right.
There is a hole between them.
When the hole shrinks to 0, <a href="gc.html" class="olink">garbage-collect</a> is invoked.
<a href="gc.html" class="olink">garbage-collect</a> slides the variable-length objects to the left and concentrates
the 2-pointer objects at the right end of the block again.
When no more room is available, some reserve area beyond the right end
of the block is halved, and the 2-pointer objects are moved to the
right accordingly.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(+)</span></p></td><td>Simple management.
</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>No fragmentation at all.
</td></tr><tr><td><p><span class="term">(-)</span></p></td><td>The total heap size is limited.
</td></tr></tbody></table></div><p>
</p></dd><dt><span class="term">SPVW_MIXED_BLOCKS_OPPOSITE &amp; TRIVIALMAP_MEMORY</span></dt><dd><p>The heap consists of two big blocks, one for
variable-length objects and one for 2-pointer objects.
The former one has a hole to the right and is extensible to the right,
the latter one has a hole to the left and is extensible to the left.
Similar to the previous model, except that the hole is unmapped.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(+)</span></p></td><td>Total heap size grows depending on the
application's needs.</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>No fragmentation at all.
</td></tr><tr><td><p><span class="term">(*)</span></p></td><td>Works only when SINGLEMAP_MEMORY is
possible as well.</td></tr></tbody></table></div><p>
</p></dd><dt><span class="term">SPVW_MIXED_BLOCKS_STAGGERED &amp; TRIVIALMAP_MEMORY</span></dt><dd><p>The heap consists of two big blocks, one for
variable-length objects and one for 2-pointer objects.
Both have a hole to the right, but are extensible to the right.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(+)</span></p></td><td>Total heap size grows depending on the
application's needs.</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>No fragmentation at all.
</td></tr><tr><td><p><span class="term">(*)</span></p></td><td>Works only when SINGLEMAP_MEMORY is
possible as well.</td></tr></tbody></table></div><p>
</p></dd><dt><span class="term">SPVW_MIXED_PAGES</span></dt><dd><p>The heap consists of many small pages (usually around 8 KB).
There are two kinds of pages: one for 2-pointer objects, one for
variable-length objects.
The set of all pages of a fixed kind is called a "Heap".
Each page has its hole (free space) at its end.
For every heap, the pages are kept sorted according to the size of
their hole, using AVL trees.
The <a href="gc.html" class="olink">garbage-collect</a>ion is invoked when the used space has grown by 25% since the
last GC; until that point new pages are allocated from the OS.
The GC compacts the data in each page separately:
data is moved to the left. Emptied pages are given back to the OS.
If the holes then make up more than 25% of the occupied storage, a
second GC turn moves objects across pages, from nearly empty ones to
nearly full ones, with the aim to free as many pages as possible.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(-)</span></p></td><td>Every allocation requires AVL tree operations,
thus slower</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>Total heap size grows depending on the
application's needs.</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>Works on operating systems which do not provide
large contiguous areas.</td></tr></tbody></table></div><p>
</p></dd><dt><span class="term">SPVW_PURE_PAGES</span></dt><dd><p>Just like SPVW_MIXED_PAGES, except that every page
contains data of only a single type tag, i.e. there is a Heap for
every type tag.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(-)</span></p></td><td>Every allocation requires AVL tree operations,
thus slower</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>Total heap size grows depending on the
application's needs.</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>Works on operating systems which do not provide
large contiguous areas.</td></tr><tr><td><p><span class="term">(-)</span></p></td><td>More fragmentation because objects of different
type never fit into the same page.</td></tr></tbody></table></div></dd><dt><span class="term">SPVW_PURE_BLOCKS</span></dt><dd><p>There is a big block of storage for each type tag.
Each of these blocks has its data to the left and the hole to the
right, but these blocks are extensible to the right (because there is
enough room between them).
A <a href="gc.html" class="olink">garbage-collect</a>ion is triggered when the allocation amount since the
last GC reaches 50% of the amount of used space at the last GC, but at
least 512 KB.
The <a href="gc.html" class="olink">garbage-collect</a>ion cleans up each block separately: data is moved left.
</p><div class="variablelist" title="Advantages and Disadvantages"><p class="title">Advantages and Disadvantages</p><table border="0"><col align="left" valign="top" /><tbody><tr><td><p><span class="term">(+)</span></p></td><td>Total heap size grows depending on the
application's needs.</td></tr><tr><td><p><span class="term">(+)</span></p></td><td>No 16 MB total size limit.
</td></tr><tr><td><p><span class="term">(*)</span></p></td><td>Works only in combination with SINGLEMAP_MEMORY.
</td></tr></tbody></table></div><p>
</p></dd></dl></div><p>In page based memory models, an object larger than a page is the
only object carried by its pages.
There are no small objects in pages belonging to a big object.</p><p>The following combinations of memory model and
<a class="unix" href="http://www.opengroup.org/susv3/functions/mmap.html"><code class="function">mmap</code></a> tricks are possible (the number
indicates the order in which the respective models have been
developed):</p><div class="table"><a id="mem-models-comb-typecodes"></a><p class="title">Table 35.1. Memory models with <a class="link" href="typecodes.html" title="35.3. Object Pointer Representations"><span class="strong"><strong><code class="option">TYPECODES</code></strong></span></a></p><div class="table-contents"><table summary="Memory models with TYPECODES" border="1"><colgroup><col /><col /><col /><col /><col /></colgroup><thead><tr><th align="center"> </th><th align="center"><a class="xref" href="memory-models.html#MMC-A">A</a></th><th align="center"><a class="xref" href="memory-models.html#MMC-B">B</a></th><th align="center"><a class="xref" href="memory-models.html#MMC-C">C</a></th><th align="center"><a class="xref" href="memory-models.html#MMC-D">D</a></th></tr></thead><tbody><tr><td align="center">SPVW_MIXED_BLOCKS_OPPOSITE</td><td align="center">1</td><td align="center">9</td><td align="center"> </td><td align="center">8</td></tr><tr><td align="center">SPVW_MIXED_BLOCKS_STAGGERED</td><td align="center"> </td><td align="center">6</td><td align="center"> </td><td align="center">7</td></tr><tr><td align="center">SPVW_PURE_BLOCKS</td><td align="center"> </td><td align="center"> </td><td align="center">4</td><td align="center">5</td></tr><tr><td align="center">SPVW_MIXED_PAGES</td><td align="center">2</td><td align="center"> </td><td align="center"> </td><td align="center"> </td></tr><tr><td align="center">SPVW_PURE_PAGES</td><td align="center">3</td><td align="center"> </td><td align="center"> </td><td align="center"> </td></tr></tbody></table></div></div><br class="table-break" /><div class="table"><a id="mem-models-comb-heapcodes"></a><p class="title">Table 35.2. Memory models with <a class="link" href="typecodes.html" title="35.3. Object Pointer Representations"><span class="strong"><strong><code class="option">HEAPCODES</code></strong></span></a></p><div class="table-contents"><table summary="Memory models with HEAPCODES" border="1"><colgroup><col /><col /><col /><col /></colgroup><thead><tr><th align="center"> </th><th align="center"><a class="xref" href="memory-models.html#MMC-A">A</a></th><th align="center"><a class="xref" href="memory-models.html#MMC-B">B</a></th><th align="center"><a class="xref" href="memory-models.html#MMC-D">D</a></th></tr></thead><tbody><tr><td align="center">SPVW_MIXED_BLOCKS_OPPOSITE</td><td align="center">*</td><td align="center">*</td><td align="center">*</td></tr><tr><td align="center">SPVW_MIXED_BLOCKS_STAGGERED</td><td align="center"> </td><td align="center">*</td><td align="center">*</td></tr><tr><td align="center">SPVW_MIXED_PAGES</td><td align="center">*</td><td align="center"> </td><td align="center"> </td></tr></tbody></table></div></div><br class="table-break" /><div class="orderedlist" title="Legend to Table 35.1, “Memory models with TYPECODES” and Table 35.2, “Memory models with HEAPCODES”"><p class="title">Legend to
<a class="xref" href="memory-models.html#mem-models-comb-typecodes" title="Table 35.1. Memory models with TYPECODES">Table 35.1, “Memory models with <span class="strong"><strong><code class="option">TYPECODES</code></strong></span></a> and
<a class="xref" href="memory-models.html#mem-models-comb-heapcodes" title="Table 35.2. Memory models with HEAPCODES">Table 35.2, “Memory models with <span class="strong"><strong><code class="option">HEAPCODES</code></strong></span></a></p><ol class="orderedlist" type="A"><li class="listitem"><a id="MMC-A"></a>no MAP_MEMORY</li><li class="listitem"><a id="MMC-B"></a>TRIVIALMAP_MEMORY</li><li class="listitem"><a id="MMC-C"></a>SINGLEMAP_MEMORY</li><li class="listitem"><a id="MMC-D"></a>GENERATIONAL_GC</li></ol></div></div><div class="bookinfo"><hr /><table width="100%" summary="impnotes meta info"><th><td align="left">These notes document <a class="ulink" href="http://clisp.cons.org" target="_top"><span class="command"><strong>CLISP</strong></span></a> version 2.49</td><td align="right">Last modified: 2010-07-07</td></th></table></div><div class="custom-footer"><hr /><table width="100%"><tr><td align="left"><a href="http://clisp.cons.org"><img src="clisp.png" width="48" height="48" alt="[CLISP home]" /></a></td><td align="center"><a href="https://sourceforge.net/donate/index.php?group_id=1355"><img src="http://images.sourceforge.net/images/project-support.jpg" width="88" height="32" alt="[Support CLISP]" /></a></td><td align="right"><a href="https://sourceforge.net/projects/clisp"><img width="120" height="30" alt="[SourceForge]" src="http://sflogo.sourceforge.net/sflogo.php?group_id=1355&amp;type=12&amp;page=memory-models" /></a></td></tr></table></div><hr /><form method="get" action="http://www.google.com/custom" target="_top"><table width="100%" border="0"><tr><td nowrap="nowrap" align="center"><input type="hidden" name="domains" value="clisp.cons.org;clisp.podval.org;www.lisp.org" /><label for="sbi" style="display: none">Enter your search terms</label><input type="text" name="q" size="50" maxlength="255" id="sbi" value="35.4. Memory Models" /><label for="sbb" style="display: none">Submit search form</label><input type="submit" name="sa" value="Google Search" id="sbb" /></td></tr><tr><td nowrap="nowrap" align="center"><input type="radio" name="sitesearch" value="" checked="1" id="ss0" /><label for="ss0" title="Search the Web"><small>Web</small></label><input type="radio" name="sitesearch" value="clisp.cons.org" id="ss1" /><label for="ss1" title="Search clisp.cons.org"><small>clisp.cons.org</small></label><input type="radio" name="sitesearch" value="clisp.podval.org" id="ss2" /><label for="ss2" title="Search clisp.podval.org"><small>clisp.podval.org</small></label><input type="radio" name="sitesearch" value="www.lisp.org" id="ss3" /><label for="ss3" title="Search www.lisp.org"><small>www.lisp.org</small></label><input type="hidden" name="client" value="pub-4445255502750357" /><input type="hidden" name="forid" value="1" /><input type="hidden" name="ie" value="UTF-8" /><input type="hidden" name="oe" value="UTF-8" /><input type="hidden" name="cof" value="GALT:#008000;GL:1;DIV:#336699;VLC:663399;AH:center;BGC:FFFFFF;LBGC:000000;ALC:0000FF;LC:0000FF;T:000000;GFNT:0000FF;GIMP:0000FF;LH:48;LW:48;L:http://clisp.cons.org/clisp.png;S:http://clisp.cons.org;FORID:1" /><input type="hidden" name="hl" value="en" /></td></tr></table></form><hr /><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="typecodes.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="gc.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="gc-safety.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">35.3. Object Pointer Representations </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 35.5. The burden of garbage-collection upon the rest of <span class="command"><strong>CLISP</strong></span></td></tr></table></div></body></html>