CSE 3341 Project 5 – Garbage Collection Overview
The goal of this project is to modify the Core interpreter from Project 4 to now handle garbage collection.
Your submission should compile and run in the standard environment on stdlinux. If you work in some other environment, it is your responsibility to port your code to stdlinux and make sure it works there.
The Heap and the Garbage Collector
You should implement reference counting for the record objects.
In essence, for each record object you need to keep track of how many references there
are to that object, i.e. for each object you need a “reference count”. It is likely you can track the reference counts in a similar way to how you track the length of the record objects. As record variables (our references) are manipulated or go out of scope, you will be incrementing and decrementing the reference counts. Once a reference count reaches 0, that object can be garbage collected. To verify that your garbage collector is working, your garbage collector will produce some output each time the number of reachable objects
Input to your interpreter
The input to the interpreter will be same as the input from Project 4 (a .code and a .data file).
Output from your interpreter
All output should go to stdout. This includes error messages – do not print to stderr.
Just like in the last project, each Core out statement should produce an integer printed
on a new line, without any spaces/tabs before or after it.
The garbage collector should output the current number of reachable objects each time
the number changes. Please follow this format: “gc:n” where n is the current number of reachable objects.
For example, consider the following program:
procedure example and { procedure add(ref a, b) is
record n; begin
n := new record[1]; n[0] := 10;
record y; begin
x := new record[1]; x[0] := 5;
y := new record[1]; y[0] := 7;
begin add(x, y);
out(x); end
During execution, this program should produce the following output (in bold):
1. gc:1 when x = new record[1]; executes
2. gc:2 when y = new record[1]; executes
3. gc:3 when n = new record[1]; executes
4. gc:2 when the call to add returns (n has gone out of scope, we’ve lost the last reference to where we put that 10)
5. 12 when outx); executes
6. gc:1 then gc:0 when program ends and x, y go out of scope
Invalid Input
There are no new errors we need to look for here.
Testing Your Project
I will provide some test cases. The test cases I will provide are rather weak. You should do additional testing testing with your own cases. Like the previous projects, I will provide a tester.sh script to help automate your testing.
Programming Help
Project Submission
On or before 11:59 pm April 7th, you should submit the following:
Your complete source code.
An ASCII text file named README.txt that contains:
– Your name on top
– The names of all the other files you are submitting and a brief description of each
stating what the file contains
– Any special features or comments on your project
– A brief description of how you tested the interpreter and a list of known remaining bugs (if any)
Submit your project as a single zipped file to the Carmen dropbox for Project 5.
If the time stamp on your submission is 12:00 am on April 8th or later, you will receive a 10% reduction per day, for up to three days. If your submission is more than 3 days late, it will not be accepted and you will receive zero points for this project. If you resubmit your
project, only the latest submission will be considered.
The project is worth 100 points. Correct functioning of the interpreter is worth 85 points. The implementation style and documentation are worth 15 points.
Academic Integrity
The project you submit must be entirely your own work. Minor consultations with others in the class are OK, but they should be at a very high level, without any specific details. The work on the project should be entirely your own; all the design, programming, testing, and debugging should be done only by you, independently and from scratch. Sharing your code or documentation with others is not acceptable. Submissions that show excessive similarities (for code or documentation) will be taken as evidence of cheating and dealt with accordingly; this includes any similarities with projects submitted in previous instances of this course.
Academic misconduct is an extremely serious offense with severe consequences. Addi- tional details on academic integrity are available from the Committee on Academic Mis- conduct (see http://oaa.osu.edu/coamresources.html). If you have any questions about uni- versity policies or what constitutes academic misconduct in this course, please contact me immediately.
程序代写 CS代考 加QQ: 749389476
Please note this is a language like C or Java where whitespaces have no meaning, and whitespace can be inserted between keywords, identifiers, constants, and specials to accommodate programmer style. This grammar does not include formal rules about whitespace because that would add immense clutter.
Recall epsilon is the empty string.
| procedure ID and
| if
CS Help, Email: tutorcs@163.com