[movitz-cvs] CVS update: public_html/movitz.html

Tue Mar 30 08:21:20 UTC 2004

Update of /project/movitz/cvsroot/public_html
In directory common-lisp.net:/tmp/cvs-serv15200

Modified Files:
	movitz.html 
Log Message:
Some re-wording.

Date: Tue Mar 30 03:21:19 2004
Author: ffjeld

Index: public_html/movitz.html
diff -u public_html/movitz.html:1.2 public_html/movitz.html:1.3

--- public_html/movitz.html:1.2	Tue Mar 30 03:04:00 2004
+++ public_html/movitz.html	Tue Mar 30 03:21:18 2004
@@ -10,7 +10,7 @@
  Author:        Frode Vatvedt Fjeld <frodef at acm.org>
  Created at:    Wed Nov  5 09:55:54 2003
                 
- $Id: movitz.html,v 1.2 2004/03/30 08:04:00 ffjeld Exp $
+ $Id: movitz.html,v 1.3 2004/03/30 08:21:18 ffjeld Exp $
                 
 -->
 
@@ -20,7 +20,7 @@
 </head>
 <body>
 <h1>Movitz: A Common Lisp OS development platform</h1>
-<tt>$Id: movitz.html,v 1.2 2004/03/30 08:04:00 ffjeld Exp $</tt>
+<tt>$Id: movitz.html,v 1.3 2004/03/30 08:21:18 ffjeld Exp $</tt>
 
 <h2><a href="files/">Files</a></h2>
 <p> The latest <a href="files/los0.img"> los0 kernel image</a> and its
@@ -139,38 +139,45 @@
 required to interface any hardware without resorting to inline
 assembly is either in place or can easily be added.
 
-<h3>Garbage Collection</h3>
+<h3>Garbage Collection</h3> <a name="GC">
 
 There is now preliminary support for GC in Muerte. This support is two
 things. Firstly, the object layouts, stack discipline, etc. are such
 that the system as such is amenable to scanning for GC
 purposes. Secondly, there are two functions in Muerte that are
-expectedly very useful for implementing many kinds of GC:
+expectedly useful for implementing GC architectures:
 <ul>
 
 <li> <tt>map-heap-words</tt> maps a function over every potential
-pointer in a specified memory region. This can be used both to
-implement GC as such (if the function migrates objects according to
-some GC scheme), and as a help for GC debugging (if the function
-merely checks some invariant or prints information). </li> <li>
-<tt>map-stack-words</tt> works similarly for a control stack. A stack
-is wrapped as a vector specialized to <tt>(unsigned-byte 32)</tt> in
-memory, so it will not recognized as pointers by
+pointer in a specified memory region, denoted by start and end memory
+locations. This can be used both to implement GC as such (if the
+function migrates objects according to some GC scheme), and as a help
+for GC debugging (if the function merely checks some invariant or
+prints information). </li>
+
+<li> <tt>map-stack-words</tt> works similarly for a control stack. A
+stack is wrapped as a vector specialized to <tt>(unsigned-byte
+32)</tt> in memory, so it will not recognized as pointers by
 e.g. <tt>map-heap-words</tt>. Hence, this function must be used
-explicitly in order to capture all pointers in the system.</li>
+explicitly over each live control stack in order to capture all
+pointers in the system.</li>
+
 </ul>
 
 The los0 image currently uses these two functions to implement a
 rather simple Cheney-style stop-and-copy GC architecture. In short,
 two 256 KB buffers are set up, and the memory allocation primitives
-are changed to allocate from one of these buffers designated
+are changed to allocate from one of these buffers designated as
 "newspace". When newspace goes full, the roles of oldspace and
-newspace are switched, and the (newly demoted) oldspace is
-evacuated. This evacuation is performed rather naively, namely by
-scanning the entire heap, which tends to be somewhere between one and
-two megabytes in los0. Note that under this simple scheme there is no
-way for objects to be promoted from the two 256 KB buffers, so you
-cannot have more than this amount of live, dynamically allocated data.
+newspace are switched, and the live objects in the (newly become)
+oldspace are evacuated into the (newly become) newspace. This
+evacuation is performed rather naively, namely by scanning the entire
+heap, which tends to be somewhere between one and two megabytes in
+los0. Note that under this simple scheme there is no way for objects
+to be promoted from the two 256 KB buffers, so you cannot have more
+than this amount of live, dynamically allocated data. Note that there
+are still several rough edges remaining this GC implementation,
+e.g. it will not behave across e.g. any kind of interrupt.
 
 <h2>About OS design in Common Lisp</h2>
 



