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

Tue Mar 30 08:04:01 UTC 2004

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

Modified Files:
	movitz.html 
Log Message:
Added info about the new GC stuff.

Date: Tue Mar 30 03:04:00 2004
Author: ffjeld

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

--- public_html/movitz.html:1.1	Tue Jan 13 08:31:59 2004
+++ public_html/movitz.html	Tue Mar 30 03:04:00 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.1 2004/01/13 13:31:59 ffjeld Exp $
+ $Id: movitz.html,v 1.2 2004/03/30 08:04:00 ffjeld Exp $
                 
 -->
 
@@ -20,7 +20,7 @@
 </head>
 <body>
 <h1>Movitz: A Common Lisp OS development platform</h1>
-<tt>$Id: movitz.html,v 1.1 2004/01/13 13:31:59 ffjeld Exp $</tt>
+<tt>$Id: movitz.html,v 1.2 2004/03/30 08:04:00 ffjeld Exp $</tt>
 
 <h2><a href="files/">Files</a></h2>
 <p> The latest <a href="files/los0.img"> los0 kernel image</a> and its
@@ -141,17 +141,36 @@
 
 <h3>Garbage Collection</h3>
 
-There is no garbage collection scheme implemented yet. Whether a fully
-operational GC <em>can</em> be part of Muerte, or whether it requires
-extensive support from the particular MoKA run-time, remains to be
-seen.
-
-I expect that it turns out that some middle ground must be found: The
-basic mechanisms and hooks needed to perform GC will be provided by
-Muerte, and the MoKA uses this to provide full GC service (if it will
-provide GC at all). In this spirit, I hope to add something like a
-simple stop-and-copy GC to los0 soon.
+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:
+<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
+e.g. <tt>map-heap-words</tt>. Hence, this function must be used
+explicitly 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
+"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.
 
 <h2>About OS design in Common Lisp</h2>
 



