The purposes of this homework are
After an initial startup phase, a garbage-collected heap reaches a steady state.To understand this assumption, recall that the mutator (a program) allocates at will, and after any allocation request, the system may decide to collect garbage. Therefore, a program's memory-related behavior can be divided into a sequence of allocation cycles, each of which consists of a sequence of allocation requests followed by a garbage collection. (When generational collection enters the picture, we have cycles within cycles.)
At startup time, there is no live data, so the heap is empty. The steady-state assumption says that, after some number of cycles in which the heap grows, eventually it reaches a steady state: that is, at the end of each collection cycle, the heap looks pretty much the same as it looked at the end of the previous cycle—provided it has reached the steady state.
Inside your local cs152 directory, create a directory called gc. Go to that directory. Copy the code for both collectors as follows:
cp -r ~cs152/software/bare/uscheme-copy . cp -r ~cs152/software/bare/uscheme-ms .
Some of the code will contain lines marked with the mysterious comment /* OMIT */. This comment marks secret code that doesn't show up in the book but is useful for homework. You are welcome to use it.
For problem 14, please print your statistics in this form:
[GC stats: heap size 192 live data 91 ratio 2.11] [Mem stats: allocated 389 heap size 408 ratio 0.95] [Total GC work: 7 collections copied 642 objects; 1.65 copies/allocation]Please use exactly two digits after the decimal point when printing ratios; if there is no live data, print the ratio as
For problem 15, be sure to explain your choice of gamma.
Our solution to part I requires about 150 lines of C code, of which only a small amount is devoted to debugging.
You may find it helpful to do problem 4 before attempting the implementation. Your solution to problem 4 can be written in ASCII.
For problem 2, please print your statistics in this form:
[GC stats: heap size 168 live data 105 ratio 1.60] [Mem stats: allocated 389 heap size 192 ratio 2.03] [Total GC work: 6 collections marked 469 objects; 1.21 marks/allocation]As above, please use exactly two digits after the decimal point when printing ratios; if there is no live data, print the ratio as
Our solution to part II requires about 150 lines of C code, of which about 60 lines are devoted to debugging.
Present your solutions to these problems in a written report. Please submit your report on paper by 5:00PM Thursday, March 2nd.
Some of the problems call for formulas that express various costs as functions of gamma. If you find it easier to do the analysis by thinking about other quantities, such as the number of cells allocated or the fraction of the heap occupied, fine, but before you turn in your work, all other quantities must be rewritten in terms of gamma, so that gamma is the only property of the heap that appears in your final answer.
Hint: for problems 7 and 18, try to adjust your experiments to make your results as consistent as possible with your formulas. Your report should say what adjustments you made and why. Consider the steady-state assumption.
We have prepared a handout that explains how to present the experimental data you will need to gather for problems 5(c), 7, 15(b), and 18. You may also find it useful to use Alex Kulesza's perl scripts to help you gather data and convert to jgraph form.
~cs152/bin/mergetest 18it will print out a definition of merge sort and a call to sort an 18-element array, so you can try
~cs152/bin/mergetest 1234 | ./uschemefor example, to try out your own interpreter. A similar script called
inserttestlets you try the exact same test but using an insertion sort. You will probably want to sort arrays of many different sizes as you gather your measurements. You should also look for other programs to measure.
We reserve the right to use different values of
exercise your collector, so you should be sure that your program
works with any positive value of
It is quite difficult to test a garbage collector, so the bulk of your grade will be based on your ability to convince us that you have implemented a correct collector. Don't forget to explain what you have done, and don't leave your explanation for the last minute!
valstatement, does it happen if you use
setinstead? And so on. Before you go into the program, you should have gathered enough evidence from probing the interpreter to incriminate some specific section of code. Finally, don't overlook Section 4.6 of the book.
For massive extra credit, you may get the ``uScheme interpreter based on context semantics'' from the instructor, and port your garbage collector to that interpreter. The key new idea is that context semantics makes scanning for roots a piece of cake.
For modest extra credit, you may attack any other problem from Chapter 4 of Ramsey and Kamin. It is the instructor's opinion that problems 16 and 19 are probably the easiest of the remaining problems.
cd ~/cs152 mkdir gc cd gc cp -r ~cs152/software/bare/uscheme-copy . cp -r ~cs152/software/bare/uscheme-ms .This software is part of the textbook software distribution.
Whether you solve all the problems or only some, we expect you to submit at most two collectors. This is what we are expecting for Parts I and II:
Submit using submit-gc.
Submit your solutions to Part III on paper. Please include a note indicating how many hours you spent on Part III.