Monday, April 22, 2002

Question:

If we are trying to make a list, where each entry contains a list of size-x free blocks, how can we mark where each list starts without a global array?

Answer:

You are allowed to have these pointers as global variables, but I recommend storing the array at the bottom of the heap... Afterall, it's a big chunk of memory where you can do whatever you want.

Question:

Am I allowed to use memmove instead of memcpy in realloc?

Answer:

Yes. Enjoy!

	Sunday, April 21, 2002

Question:

As a starting point, my partner and i simply typed the code from the book into mm.c (incl. find_fit and place) and ran it, but we got a core dump and an error on 'trace 0'

I've read the chapter and conceptually understand what is going on, but when it comes to implementation i am struggling. Can someone explain why the book code is faulty, so that i can have a jumping off point?

Answer:

I don't believe the book's code is faulty. Perhaps you made a mistake in transcribing from the book to your own code? You should attempt running it in gdb and see where it segfaults.

Also, rather than trying to retype code by hand, I recommend that you just copy the file. You can get it at:

http://csapp.cs.cmu.edu/public/ics/code/vm/malloc.c

But, you always need to look carefully at the interface descriptions to make sure the sample code satisfies all of the requirements of the code you are asked to write.

Question:

I noticed that the given implementation of realloc() uses memcpy() to copy data; are we allowed to use this in our implementation as well?

Answer:

Yes.

Question:

I have a question regarding the mm_realloc function. If mm_realloc is called with a size that is smaller than the current block size, then it seems that one should be able to just put the new size in the header and footer and then return a pointer to the same block. However, implementing this method results in the error message: mm_realloc did not preserve the data from the old block

What I am missing here?

Answer:

The semantics for realloc when it gets a size smaller than the old block is that the bottom n bytes are to remain the same.

Make sure that you don't have an off-by-one error where you're overwriting the last byte expected to remain the same.

Your method seems fine, however.

Question:

Am I allowed to use memmove instead of memcpy in realloc?

Answer:

Sure! Enjoy.

	Saturday, April 20, 2002

Question:

In working on the malloc lab, I first implemented mm.c with an implicit list and after achieving success then implemented mm.c with a free list using LIFO.

My concern is that my free list implementation yielded a lower performance index (a slightly higher Average throughput and a slightly lower memory utilization) than my implicit list implementation.

Is this something that should be expected or have I most likely implemented the free list version incorrectly? The reason that I ask is that I want to be sure that my free list version is correct before moving on to a more complicated implementation.

Answer:

LIFO isn't a very space efficient policy. It doesn't surprise me that it yielded a worse-than-random performance in this respect. But, it doesn't involve a lot of overhead, so it doesn't surprise me that it was a slight time win -- but since implicit lists are also pretty cheap, especially when frees and allocs are mixed in ways that prevent long searches, I'm not surprised that it is only sligtly faster.

But, of course, the fact that these measurements to not indicated a flaw does not mean that the algorithms are implemented flawlessly. The problem with "proof by example" is that it only works when you are in possession of an example -- "proof by no example, right now" falls into the same category as "prof by intimidation", "proof by optimism", or, my favorite, "proof by approaching deadline".

Question:

When we run mtest for all the test cases, we get a seg fault at binary-bal.rep. However, when we run each test case seperately, they all work. Is this a problem with the grading script, or an error in our code?

Answer:

You might not be reinitializing correctly. Check your mm_init() function to make sure it does exactly what it's supposed to. That's about all I can think of off hand. Your code shouldn't crash when mtest runs through everything. You may want to run it in gdb to see where it's crashing.

	Tuesday, April 16, 2002

Question:

What would cause the error "ERROR: mem_sbrk failed. Ran out of memory..."?

Answer:

Remember that you use sbrk to extend the heap. If the heap gets too large, that means too many pages have been allocated to it before it starts encroaching on stack space.
There isn't any reason that you should run out of memory for any of these tests. Depending on the trace file, it could mean that your malloc has a serious bug, or that you haven't implemented some of the more advanced features yet (i.e., coalescing).

Question:

Are we allowed to declare static global variables? Also, where are static global variables managed in the virtual memory?

Answer:

It's okay to declare some void *, int, or other base type variables as static global. Don't declare any global structs, etc, as the lab says.

Question:

How is casting to (size_t *) different from casting to (void *)?

Answer:

Casting to size_t * makes makes a pointer to a size_t object. Casting to void * creates a generic pointer. The difference is that void objects do not have any size, a void pointer is merely a standardized way to pass pointers to anything around.

	Monday, April 15, 2002

Question:

How do you test mm.c, i.e. how do you use mtest.c?

Answer:

Just type make to compile mtest. Then run ./mtest and it will run all the trace files. ./mtest -h will give you some more options.

	Sunday, April 14, 2002

Question:

Our group was thinking of an implementation of Malloc that is somewhat different from the suggested Segregated free lists that was described in class. We'd like to know your opinions regarding the idea.

Answer:

Anything you can think of to do better is always great. If you feel you have the time, implement it and see if it works. However, perhaps you should make sure you have a working implementation before tackling anything too complicated.