In this assignment you will be writing a program to simulate memory management, and also comparing several different approaches to satisfying requests and defragmenting memory. The basic idea is that memory is kept as a set of free blocks, each with a starting address and size. As requests for memory arrive, allocations are satisfied by using all or a portion of a free block, with the leftover being returned to the set of available memory. When memory is deallocated (no longer needed), the block it used gets returned to the free set. Eventually there are many adjacent small blocks on the free list that could be combined to form larger blocks - this is called defragmenting.
We will assume that each free block of memory has a starting address and a size, in bytes. Initially your program will be given one piece of information: the total number of bytes in memory. We assume at the start that it is one large contiguous free block with starting address 0. Then your program will need to process a list of memory allocation and deallocation requests. The format for these requests will be very simple. "A 12" is a request to allocate a block of 12 bytes. (Note that all bytes satisfying a request must be contiguous in memory.) When an allocation is requested it is given a unique ID number (regardless of whether it is ultimately satisfied or fails). ID numbers must start at 1, not 0. In order to deallocate some memory space, we use the allocation ID number: "D 15" will free the block associated with allocation request 15 (if it exists in the allocated section). The memory that was used then gets returned to the set of available blocks. All the input (memory size and alloc/dealloc requests) will come from a plain text input file, one request (allocate or deallocate) per line.
It is likely that after some time, an allocation request will be denied because there isn't a free block large enough to satisfy it. At that point, your program will partially defragment the available memory by joining all adjacent free blocks into the largest blocks possible. This is not a full defrag, so do not move allocated blocks in memory! After the partial defrag, make one more attempt to satisfy the request. If it still can't fit into an available block, then that request fails.
Now, there are several different schemes for allocating memory. And, as you all might expect by now, there are several different data structures that can be used to implement them. Part of the goal of this assignment is to do a performance analysis of three different allocation schemes, each of which is implemented with a different data structure. Of these schemes, the first two are used in practice. The third one is fabricated for the purpose of this assignment. Remember that for each of these schemes any unused portions of the block chosen are returned to the free space store (available memory).
In order to defragment memory efficiently, you will need to sort the free blocks by memory address. You must implement and compare two different sorting strategies: the quicksort and the bucketsort.
Performance Analysis: There are several different measures that you will need in order to compare the approaches. Each of these measures must be independently applied to each of the three allocation strategies. Note that an allocation request is only considered to have failed if it can't be satisfied after (partial) defragmenting.
You should report these performance measurements in a table which has a column for each memory allocation strategy (3 total). It will have six rows: one for each of the memory alloc measures (4 total), and one for the averaged ratios of time/size of each sort (2 sort strategies total).
In order to time various operations, you can use System.currentTimeMillis() as we did in the last assignment. It is possible that a block runs so quickly (for small data sets) that the difference between the start and end times will be 0. If you find this is the case (test it!), then you might need to pad the block with extra statements in order to slow down execution somewhat. Print statements are usually good for something like this, however, you will need to make sure that the same exact padding is given to the other blocks you are comparing. If you use padding, please include that information with your performance analysis output.
Program Output: Your program must create two different output files. One file, called "analysis.txt" will contain your performance analysis chart and any related information, as described above. Make sure this is nicely formatted and labelled so it is easy to read and draw conclusions from. The second file, called "translog.txt" will be a log of the transaction requests and results of each, one transaction per line, in the order in which they occurred. It must have columns corresponding to each of the three memory allocation strategies. In this log file, identify each allocation request by the code "A", the size of the request and the assigned ID (this should be the same for all allocation strategies, and remember to start counting with 1, not 0). The results (for each alloc strategy) will be either the starting memory address of where it was allocated or a failed indicator, and also a "DF" if the request caused a defragmentation. There should also be a line for each deallocation request indicated by a "D" and the ID, and the result for each strategy indicating whether it was successful or invalid. All the transactions should appear in the same order that they occur in the input file.
Coding Requirements: You must do an object oriented solution. Use multiple classes, generics, etc. to organize the processing. You must use JUnit testing for at least 3 different program features or classes. With proper citation, you may (and should) re-use code from prior assignments, and from the text. You may use some Java API Collection classes such as String, ArrayList, LinkedList, and TreeSet (for the BBST). You may not use the Java API classes as a substitute for implementing your own heap (priority queue), hash table, or sorting methods.
Hints: First of all, your program will need three different memory spaces, one for each allocation scheme. You might find it helpful to create an interface for all the common memory features, and then implement it for each allocation scheme. Also, because there are two different sorting algorithms to use for defragmenting, you will need to create a copy of your memory blocks before sorting, and then delete the second copy afterwards. Note that only one sorted copy (the one you keep) needs to actually have the blocks combined for the defragmentation part. That shouldn't be done twice.
For this part of the assignment, you are required to submit two documents as precursors to the actual coding phase: a large test suite, and a design and development plan. Both of these documents should be a combination of text and diagrams to communicate your intents, as detailed below. Save each and upload to Blackboard as pdf files only. A solution to the design plan will be distributed, so no late assignments!
Only one student per group should submit both of these files. Make sure that both documents include the full names and Blackboard logins for all group members. You will all receive the same grade! Remember to submit pdf files only.
This is the coding and testing phase of your assignment. All students in a group will receive the same grade! You should test each other's code as ruthlessly as possible. You will also be evaluating yourselves and each other at the end of the project.
There is a team evaluation that every student must individiually complete and submit on Blackboard. You do not have to submit paper copies. It will contain information about group meetings, so you should be updating it as the project unfolds. It also will give you some hints regarding important factors when working in a group, so read through it before you start.