|
@@ -4199,12 +4199,6 @@ the procedure call stack. These addresses are called the \emph{root
|
|
|
transitively reachable from the root set. Thus, it is safe for the
|
|
|
garbage collector to reclaim the tuples that are not reachable in this
|
|
|
way.
|
|
|
-%
|
|
|
-\footnote{The sitation in Figure~\ref{fig:copying-collector}, with a
|
|
|
- cycle, cannot be created by a well-typed program in $R_3$. However,
|
|
|
- creating cycles will be possible once we get to $R_6$. We design
|
|
|
- the garbage collector to deal with cycles to begin with, so we will
|
|
|
- not need to revisit this issue.}
|
|
|
|
|
|
So the goal of the garbage collector is twofold:
|
|
|
\begin{enumerate}
|
|
@@ -4214,17 +4208,22 @@ So the goal of the garbage collector is twofold:
|
|
|
\emph{garbage}.
|
|
|
\end{enumerate}
|
|
|
A copying collector accomplishes this by copying all of the live
|
|
|
-objects into the ToSpace and then performs a slight of hand, treating
|
|
|
-the ToSpace as the new FromSpace and the old FromSpace as the new
|
|
|
-ToSpace. In the example of Figure~\ref{fig:copying-collector}, there
|
|
|
-are three pointers in the root set, one in a register and two on the
|
|
|
-stack. All of the live objects have been copied to the ToSpace (the
|
|
|
-right-hand side of Figure~\ref{fig:copying-collector}) in a way that
|
|
|
-preserves the pointer relationships. For example, the pointer in the
|
|
|
-register still points to a 2-tuple whose first element is a 3-tuple
|
|
|
-and second element is a 2-tuple. There are four tuples that are not
|
|
|
-reachable from the root set and therefore do not get copied into the
|
|
|
-ToSpace.
|
|
|
+objects from the FromSpace into the ToSpace and then performs a slight
|
|
|
+of hand, treating the ToSpace as the new FromSpace and the old
|
|
|
+FromSpace as the new ToSpace. In the example of
|
|
|
+Figure~\ref{fig:copying-collector}, there are three pointers in the
|
|
|
+root set, one in a register and two on the stack. All of the live
|
|
|
+objects have been copied to the ToSpace (the right-hand side of
|
|
|
+Figure~\ref{fig:copying-collector}) in a way that preserves the
|
|
|
+pointer relationships. For example, the pointer in the register still
|
|
|
+points to a 2-tuple whose first element is a 3-tuple and second
|
|
|
+element is a 2-tuple. There are four tuples that are not reachable
|
|
|
+from the root set and therefore do not get copied into the ToSpace.
|
|
|
+(The sitation in Figure~\ref{fig:copying-collector}, with a
|
|
|
+cycle, cannot be created by a well-typed program in $R_3$. However,
|
|
|
+creating cycles will be possible once we get to $R_6$. We design
|
|
|
+the garbage collector to deal with cycles to begin with, so we will
|
|
|
+not need to revisit this issue.)
|
|
|
|
|
|
\begin{figure}[tbp]
|
|
|
\centering
|
|
@@ -4234,11 +4233,6 @@ ToSpace.
|
|
|
\label{fig:copying-collector}
|
|
|
\end{figure}
|
|
|
|
|
|
-%% \margincomment{\tiny Need to add comment somewhere about the goodness
|
|
|
-%% of copying collection, especially that it doesn't touch
|
|
|
-%% the garbage, so its time complexity only depends on the
|
|
|
-%% amount of live data.\\ --Jeremy}
|
|
|
-
|
|
|
There are many alternatives to copying collectors (and their older
|
|
|
siblings, the generational collectors) when its comes to garbage
|
|
|
collection, such as mark-and-sweep and reference counting. The
|