Requirements of Memory Management, continued

Sharing:

Even with protection, there is also a need to allow processes to share memory. For example, multiple processes running the same program can share the (read+execute only) instructions for the program, and co-operating processes may wish to share and communicate via memory containing data structures.

Relocation:

In a multi-programming system, the execution of a single process is often unrelated to others. When a process is first created, it is difficult (if not impossible) to know where its image will be placed when initially loaded into physical memory.

Similarly, when a process is swapped-out (Suspended), it is unlikely that the process will be swapped-in back to exactly the same physical memory location (address).

Memory management determines where both instructions and data are located, i.e. how a process's memory references (requests) translate into actual physical memory addresses.

Protection:

Each process must be protected from either accidental or deliberate "interference" from other processes. Although compilers for high-level programming languages offer some support (e.g. constrained control flow, static array bound references), most data references are dynamic (array access and pointer following).

Memory references made by a process must be checked (at run-time) to ensure that they lie within the bounds of memory allocated by the operating system.

Checks are performed by hardware at run-time, and invalid references generate an access violation interrupt, trap, or exception, for the operating system software to handle.

The memory protection must be performed by the processor (hardware) rather than the operating system (software), because the operating system cannot anticipate all the memory references that a program will make. Even if this were possible, it would be prohibitively time-consuming to screen each program in advance for possible memory violations.