Your malloc must pass all correctness tests before it will show up on the leaderboard.
Note that this leaderboard only tests the heaplib implementation. Due to prohibitive server loads, ensuring the correctness of your spinlocks is not accounted for in the P6 malloc leaderboard. It is up to you to ensure that your lock/unlock functions work as intended.

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 maintenance column.

There are two ranked colums:

• Overhead: sees how many small alloc requests your code can perform before returning NULL.
• Utilization: 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 mean you service 2,500 calls in 1 cycle.) If you do not have a score at all, it means your code timed out after 1 minute.

---