Written: Garbage Collection
We have discussed why, at least on paper, mark-and-sweep is an inferior garbage collection strategy for languages that permit implementations to move data in memory. Yet even for such languages, most memory managers use a mark-and-sweep strategy for their large-object space.
- Give one reason why mark-and-sweep might be preferable on such objects.
- State two standard objections to mark-and-sweep, and explain why they don't apply in this context. For each reason, first state the objection, then explain why it doesn't apply.
Suppose we have multiple kinds of data of different sizes. In typical heap representations, the type tag is always at the first address (i.e., at offset 0) that represents a value. Is it possible to construct a usable heap representation where the type tag is somewhere different? Is it desirable? Why or why not? (The more concrete you are, the more brief you can be.)
A generational garbage collector naturally handles references from newer objects (those allocated more recently) to older ones. A major challenge is keeping track of references that go the other way: from old objects to new. What in the design of a copying generational collector makes it straightforward for the collector to handle references from new to old, rather than vice versa? Remember that you may need to distinguish between variable and value mutation.
Turn in your answer to each problem in a separate text file labeled 1.txt, 2.txt., etc. We will not grade homeworks that are not submitted in this format.
From the directory containing the files for this assignment, execute