next up previous
Next: Using the Code Up: Implementation Details Previous: Standalone Library

Kernel Memory Management

Since Nachos/486 has no external environment managing resources for it, it becomes imperative that it take on certain responsibilities. Given the dynamic nature if the Nachos operating system, memory management becomes a very serious issue. Unlike a traditional monolithic UNIX kernel implementation with compile time bound constants governing the number and amount of resources available at run-time, Nachos/486 is completely dynamic. Initially the kernel has no per-thread data structures allocated. When it begins the main thread it must already be able to allocate memory for its stack!

On account of these needs, a KernelMemoryManager class was designed and implemented to allocate and deallocate regions of memory. Since we initially do not anticipate heavy demands, we chose a simple and direct implementation using two classes UsedMemoryList and FreeMemoryList which were derived from a single class MemoryList. This class is the only global object in the Nachos/486 operating system. This is necessary because it must always be in existance and it cannot be allocated without developing a ``chicken-and-egg'' ordering problem. Upon inspection of the start() routine it should be noted that the new operator is being applied to construct an instance of the KernelMemoryManager. The important point to notice is that it uses the placement version of the operator which does not request memory from any external memory management routines, but simply assumes the coder knows what he or she is doing by picking the site for the new object. In our case, we construct it into the statically allocated memory in the bss segment.

Following is a per-class and per-function summary of the features of the kernel memory management system:



next up previous
Next: Using the Code Up: Implementation Details Previous: Standalone Library



Paco Hope
Wed Jun 21 23:54:28 EDT 1995