4 ms·

Here's an old link: https://www.cs.cmu.edu/afs/cs/academic/class/15213-f10/www/labs/malloclab-writeup.pdf https://www.cs.cmu.edu/afs/cs/academic/class/15213-f10

• mutagen 9y ago
  >Because we are running on 64-bit machines, your allocator must be coded accordingly, with one exception: the size of the heap will never be greater than or equal to 232 bytes. This does not imply anything about the location of the heap, but there is a neat optimization that can be done using this information. However, be very, very careful if you decide to take advantage of this fact. There are certain invalid optimizations that will pass all the driver checks because of the limited range of functionality we can check in a reasonable amount of time, so we will be manually looking over your code for these violations. I’m curious about these optimizations and the issues that arise, any pointers on more reading?
  • tzahola 9y ago
    I might be wrong but the heap size being at most 232 bytes means that heap blocks can be represented by two bytes: one byte for the start offset, and one byte for its length.
    • jjoonathan 9y ago
      It's 2 to the 32nd power, not 232 :-)
      • tzahola 9y ago
        Oh well, that makes more sense than 232. But then again, it lets you fit the bookkeping data into a single 64bit word (32bit pointer + 32bit size).