Memory Management Tasks Accommodation of multiple processes in memory   Memory needs to be allocated efficiently Allow as many processes into memory as possible. To fit as larger processes into memory as possible. Improve the overall performance of the system. Memory Operations Fetch instruction from the Memory Operands fetching from the memory Store the result back into the memory Sometimes we can ignore how a memory address is generated by a program. and be interested in only the sequence of memory addresses generated by the running program.

How the process interacts with the memory during its lifetime

Address Binding Most systems allow a user process to reside in any part of the physical memory. Although the address space of the computer starts at 00000, the first address of the user process does not need to be 00000. Addresses in the source program are generally symbolic (such as count). A compiler will typically bind these symbolic addresses to relocatable addresses (such as "14 bytes from the beginning of this module"). The linkage editor or loader will in turn bind these relocatable addresses to absolute addresses (such as 74014). Each binding is a mapping from one address space to another.

How the binary code could be relocatable ? recall

Address Binding at compile time Binary code is different (non relocatable) If the instructions contain absolute addresses then that code is not relocatable. To make the code relocatable the compiler should use only relative addresses based on some base register(s) value.

Address Binding at link time Object Modules can be relocatable But the linker can bind the module addresses to the absolute addresses

Address Binding Compile time: If you know at compile time where the process will reside in memory, then absolute code can be generated. If, at some later time, the starting location changes, then it will be necessary to recompile this code. Static Link time: . . . Load time: If it is not known at compile time where the process will reside in memory, then the compiler must generate relocatable code. In this case, final binding is delayed until load time. If the starting address changes, we need only to reload the user code to incorporate this changed value. Execution time: If the process can be moved during its execution from one memory segment to another, then binding must be delayed until run time. Special hardware must be available for this scheme to work. Most general-purpose OS use this method. Address binding could be done at dynamic link time Dynamic Link time: . . . (again run time)

Logical Versus Physical Address Space How many relocation registers we need for 3 processes running concurrently on one CPU? How many relocation registers we need for 3 processes running on two CPUs? an address generated by the CPU is commonly referred to as a logical address (virtual address) whereas an address seen by the memory unit is commonly referred to as a physical address. The set of all logical addresses generated by a program is a logical-address space The set of all physical addresses corresponding to these logical addresses is a physical-address space. Thus, in the execution-time address-binding scheme, the logical- and physical-address spaces differ. The run-time mapping from virtual to physical addresses is done by a hardware device called the memory-management unit (MMU)   . Logical Address Space 000 . . . 346 500 Virtual Address Physical Address 14000 14500 000000 FFFFFF 000 - 500 R+000 .. R+500 Base or relocation register scheme

Memory Protection The goals The operating system should be protected from access by user processes User processes should be protected one from another How to implement We first need to make sure that each process has a separate memory space and can access only that memory space we need the ability to determine the range of legal addresses We can provide this protection by using two registers, usually a base and a limit The base register holds the smallest legal physical memory address; the limit register specifies the size of the range This protection must be provided by the hardware.

Memory Protection Hardware hardware compares every address generated in user mode with the registers. Any attempt by a program executing in user mode to access operating-system memory or other users' memory results in a trap to the operating system, which treats the attempt as a fatal error. This scheme prevents a user program from (accidentally or deliberately) modifying the code or data structures of either the operating system or other users. The base and limit registers can be loaded only by the operating system, which uses a special privileged instruction. The operating system, executing in kernel mode, is given unrestricted access to both operating system memory and users' memory. This provision allows the operating system to load users' programs into users' memory, to dump out those programs in case of errors, to access and modify parameters of system calls, and so on.

Memory Protection and Relocation Hardware How many relocation and limit registers we need for 3 processes running concurrently on one CPU? How many relocation and limit registers we need for 3 processes running on two CPUs? Can the user program change the relocation and limit registers values to access the physical storage wherever it needs? With relocation and limit registers each logical address must be less than the limit register; the MMU maps the logical address dynamically by adding the value in the relocation register. This mapped address is sent to memory When the CPU scheduler selects a process for execution, the dispatcher loads the relocation and limit registers with the correct values as part of the context switch.

Dynamic Loading Loading of some modules or libraries is being postponed until their execution time. Routine is not loaded until it is called Better memory-space utilization; unused routine is never loaded. Useful when large amounts of code are needed to handle infrequently occurring cases. OS not involved in the modules organization. The user program is responsible for it. So module sharing between different protected processes is not possible

Dynamic Linking and Shared Libraries Rather than loading being postponed until execution time, linking is postponed. OS involved in the modules organization. So module sharing between different protected processes is possible. This is shared libraries approach. Disadvantage: The sharing of the same library between different processes and the frequent updates cause version conflict and complexity of update implementation.

Swapping A process needs to be in memory to be executed. A process, however, can be swapped temporarily out of memory to a backing store and then brought back into memory for continued execution Normally a process that is swapped out will be swapped back into the same memory space that it occupied previously. If binding is done at assembly or load time, then the process cannot be moved to different locations. If execution-time binding is being used, then a process can be swapped into a different memory space, because the physical addresses are computed during execution time.