Homework 4: Malloc and FreeImportant DatesQuestions about the project? Send them to Deadline: ObjectivesThere are three objectives to this assignment:
NotesYou are allowed to have a partner. Added 3/13: You should write your own data structures to manage free space, and you should never call malloc(). OverviewIn this project, you will be implementing a memory allocator for the heap of a user-level process. Your functions will be to build your own malloc() and free() functions. Memory allocators have two distinct tasks. First, the memory allocator asks the operating system to expand the heap portion of the process's address space by calling either sbrk or mmap. Second, the memory allocator doles out this memory to the calling process. This involves managing a free list of memory and finding a contiguous chunk of memory that is large enough for the user's request; when the user later frees memory, it is added back to this list. This memory allocator is usually provided as part of a standard library and is not part of the OS. To be clear, the memory allocator operates entirely within the address space of a single process. When implementing this basic functionality in your project, we have a few
guidelines. First, when requesting memory from the OS, you must use the
mmap() system call; more about this below. Second, although a real memory
allocator requests more memory from the OS whenever it can't satisfy a request
from the user, your memory allocator must call mmap only one time (when it is
first initialized). Third, you are free to use any data structures you want to
manage the free list Classic malloc() and free() are defined as follows:
For simplicity, your implementations of Mem_Alloc(int size) and Mem_Free(void *ptr) should basically follow what malloc() and free() do; see below for details. You will also provide a supporting function, Mem_Dump(), described below; this routine simply prints which regions are currently free and should be used by you for debugging purposes. Required ReadingThis project needs you to understand a few fundamentals before proceeding. Thus, we suggest the following from the free online operating systems book, Operating Systems: Three Easy Pieces:
Program SpecificationsFor this project, you will be implementing several different routines as part of a shared library. Note that you will not be writing a main() routine for the code that you handin (but you should implement one for your own testing). We have provided the prototypes for these functions in the file mem.h (also available at ~cs354-3/public/hw4/mem.h once you log into a Linux machine); you should include this header file in your code to ensure that you are adhering to the specification exactly. You should not change mem.h in any way! We now define each of these routines more precisely.
You must provide these routines in a shared library named "libmem.so". Placing the routines in a shared library instead of a simple object file makes it easier for other programmers to link with your code. There are further advantages to shared (dynamic) libraries over static libraries. When you link with a static library, the code for the entire library is merged with your object code to create your executable; if you link to many static libraries, your executable will be enormous. However, when you link to a shared library, the library's code is not merged with your program's object code; instead, a small amount of stub code is inserted into your object code and the stub code finds and invokes the library code when you execute the program. Therefore, shared libraries have two advantages: they lead to smaller executables and they enable users to use the most recent version of the library at run-time. To create a shared library named libmem.so, use the following commands (assuming your library code is in a single file "mem.c"): gcc -c -fpic mem.c -m32 gcc -shared -o libmem.so mem.o -m32 To link with this library, you simply specify the base name of the library with "-lmem" and the path so that the linker can find the library "-L.". gcc -m32 -o myprogram mymain.c -L. -lmem Of course, these commands should be placed in a Makefile. Before you run "myprogram", you will need to set the environment variable, LD_LIBRARY_PATH, so that the system can find your library at run-time. Assuming you always run myprogram from this same directory, you can type: setenv LD_LIBRARY_PATH . Of course, you may be using a shell that does not support the above syntax (which is csh, or the C shell), such as bash. In bash, you would have to type:
export LD_LIBRARY_PATH=. Operating System HintsIn this project, you will use mmap to map zero'd pages (i.e., allocate new pages) into the address space of the calling process. Note there are a number of different ways that you can call mmap to achieve this same goal; we give one working example here: // open the /dev/zero device int fd = open("/dev/zero", O_RDWR); // region_size (in bytes) needs to be evenly divisible by the page size void *ptr = mmap(NULL, region_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); if (ptr == MAP_FAILED) { perror("mmap"); return -1; } // close the device (don't worry, mapping is unaffected) close(fd); return 0; GradingYour implementation will be graded along two main axes:
Handing in your CodeHand in your source code and a README file. The usual place: ~cs354-3/handin/NAME/hw4/, where NAME is your login name. You should copy all of your source files (*.c and *.h) and a Makefile to your hw4/ handin directory. Do not submit any .o files. If you have a partner, put the code in ONE of your directories, and a file called PARTNER.txt in BOTH handin directories (one per partner). In that file should be the login of both partners. . . |