Your malloc must pass all correctness tests before it will show up on the leaderboard.

Note: your placement on the leaderboard is not directly related to your grade (although it will point out awesomeness and awfulness). It's there to show you the tradeoffs associated with your implementation. If someone does something very sophisticated, it might translate to more overhead. Their score would be worse in the overhead column, but might be better in the performance or maintenance columns (coming soon).

There are four ranked colums:

• Overhead: sees how many small alloc requests your code can perform before returning NULL. (Allocates a 4K heap and then repeatedly requests 1 byte blocks. 255 means your heaplib was able to give out 255 1 byte blocks before it ran out of room.)
• Maintenance: the maintenance test performs a series of alloc, resize, and free calls. Your score is how many of the alloc and resize requests did not return NULL.
• Success Rate and Throughput: the final test creates a very large heap and then makes 10 million calls of either alloc, free, or resize. The large heap should mean that most requests can be fulfilled, but because it is randomized, they will not all be possible. A Success Rate score of 70-75% is considered normal. Anything significantly higher or lower means you are doing something awesome or not so awesome. Your Throughput score measures how many 1,000 alloc/resize/free calls your heaplib can service in a single clock cycle. (so 2.5 would me you service 2,500 calls in 1 cycle.) Note that the scores of columns 3 and 4 come from the same experiment but are sorted independently. If you do not have a score at all, it means your code timed out after 1 minute.