|
|
@@ -25,7 +25,7 @@
|
|
|
|
|
|
\def\racketEd{0}
|
|
|
\def\pythonEd{1}
|
|
|
-\def\edition{0}
|
|
|
+\def\edition{1}
|
|
|
|
|
|
% material that is specific to the Racket edition of the book
|
|
|
\newcommand{\racket}[1]{{\if\edition\racketEd{#1}\fi}}
|
|
|
@@ -11162,6 +11162,16 @@ class TypeCheckLtup(TypeCheckLwhile):
|
|
|
\section{Garbage Collection}
|
|
|
\label{sec:GC}
|
|
|
|
|
|
+
|
|
|
+%% Def. The *live data* are all of the tuples that might be accessed by
|
|
|
+%% the program in the future. We can overapproximate this as all of the
|
|
|
+%% tuples that are reachable, transitively, from the registers or
|
|
|
+%% procedure call stack. We refer to the registers and stack collectively
|
|
|
+%% as the *root set*.
|
|
|
+
|
|
|
+%% The goal of a garbage collector is to reclaim the data that is not
|
|
|
+%% live.
|
|
|
+
|
|
|
Here we study a relatively simple algorithm for garbage collection
|
|
|
that is the basis of state-of-the-art garbage
|
|
|
collectors~\citep{Lieberman:1983aa,Ungar:1984aa,Jones:1996aa,Detlefs:2004aa,Dybvig:2006aa,Tene:2011kx}. In
|
Jeremy Siek