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@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>