Contiguous Memory Allocation Techniques

1. Our basic goal in studying contiguous allocation techniques is to identify some basic issues underlying memory management (which we will later see can be better addressed using non-contiguous allocation techniques).
2. In such a scheme, memory will be wasted in situations where the available partitions sizes don't match the memory requirements of the processes to be executed.
   • If we put a small job in a large partition, much of the space in the partition will be wasted. In such cases, the wasted space is said to be the result of internal fragmentation.
   • We may also face situations where we have processes to run, but all the free partitions are just a bit too small for them. In this case, the wasted space is said to be the result of external fragmentation.
   To avoid wasting tremendous amounts of memory, a system needs to use a variety of partitions sizes.
3. As hinted earlier, there will be significant interactions between the memory allocator and the scheduler.
   • Using static partitions in a naive way with many of the simple scheduling techniques we discussed would be disastrous. (Consider what happens to a FCFS or strict priority long-term scheduler if the next job to be run happens to require a large partition which will remain in use long after many smaller partitions become free.)
   • Even a very intelligent scheduler is bound to make some mistakes.

     (What should a scheduler do if it has only one job needing a small partition to run and only one large partition free? If it starts the job, it may be surprised to find that the job takes a long time and a big-memory, short-time job arrives right after it assigns the large partition to the small memory job. If it waits, it may be surprised to find that no large jobs arrive for a long time.)

4. Swapping: Scheduling problems can be relieved if memory allocations can be preempted.
   • To make this possible, the contents of the memory segment allocated to the process must be saved to disk (or other external memory) to save the state of the processes data areas, and later transferred back to memory before the process can be restarted. This process is called swapping.

   • A less common but possible scheme would be to move the processes memory contents directly to another partition.
5. Relocation: Swapping a process back into a slot different from which it was preempted raises the problem of relocation.
   • A running process may store pointers to words in memory in registers (including the SP and FP) or other memory words (pointer variables). If a process is moved, these addresses become invalid.
   • One possible solution is to make all `pointers' relative to a few know registers (PC, SP, FP) and then just adjust these registers if the process is moved.
     • This solution has been used to minimize relocation problems at process start-up time.
     • This technique is INFLEXIBLE.

       No absolute address can ever, even temporarily be placed in any location other than one of the automatically relocated registers.

   • A better solution is to transparently `relocate' all addresses used by the program.
     • As mentioned earlier, the memory protection scheme suggested for resident monitor can be extended to multi-partition systems if the hardware provides a pair of `low-bound/high-bound' registers. Such registers are often referred to as base/bounds registers.
     • Suppose that we design the processor so that when user code is running, the value in the low-bound register is added to every address the process references.
     • The result is that every process thinks it is

       executing in words 0 through `bounds' regardless of the actual partition to which it is assigned.

   • The use of base/bounds registers to relocate addresses introduces the abstraction of a virtual address space.
6. Dynamic Contiguous Allocation
   • An obvious alternative to static allocation of partitions is to have the system allocate partitions dynamically as processes are created. That is, have the system keep track of:
     • The start address and size of the area of memory assigned to each active process - the used list.
     • The start address and size of each unused area in memory - the free list.. (this information can be stored in the free area itself).
     and then
     1. when a new process is created:
        • Find a free area large enough for the process.
        • Split the free area into an area big enough for the new process and a 'left over' area.
        • Associate the part of the area for the process with the process in the used list and add the left over area to the free list.
     2. when a process terminates:
        • Remove the area associated with the process from the used list.
        • Return the area to the free list, coalescing it with any contiguous free areas.
   • Dynamic allocation does away with internal fragmentation, but one can still get external fragmentation if the areas in the free list are all too small for the waiting processes.
   • There are two main choices of how to "find a free area large enough" for a process.
     • First fit (next fit) - take the first one that is big enough.
     • Best fit - search the whole list for the smallest free area that is big enough.
     Surprisingly, simulation and experimental studies have found that first fit works better because best fit has a tendency to leave tiny little free areas that you can't do anything with.
7. Dynamic allocation & compaction
   • One way to deal with external fragmentation in a dynamically allocated system is to move the allocated partitions around so that all the free areas can be coalesced.

     Moving the data in large areas of memory is, unfortunately, expensive.