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