Chapter 8, Main Memory

1. Chapter 8, Main Memory

2. 8.1 Background • When a machine language program executes, it may cause memory address reads or writes • From the point of view of memory, it is of no interest what the program is doing • All that is of concern is how the program/operating system/machine manage access to the memory

3. Address binding • The O/S manages an input queue in secondary storage of jobs that have been submitted but not yet scheduled • The long term scheduler takes jobs from the input queue, triggers memory allocation, and puts jobs into physical memory • PCB’s representing the jobs go into the scheduling system’s ready queue

4. The term memory address binding refers to the system for determining how memory references in programs are related to the actual physical memory addresses where the program resides • In short, this aspect of system operation stretches from the contents of high level language programs to the hardware the system is running on

5. Variables and memory • 1. In high level language programs, memory addresses are symbolic. • Variable names make no reference to an address space in the program • But in the compiled, loaded code, the variable name is associated with a memory address that doesn’t change during the course of a program run • This memory location is where the value of the variable is stored

6. Relative memory addresses • 2. When a high level language program is compiled, typically the compiler generates relative addresses. • This means that the loaded code contains address references into the data and code space starting with the value 0 • Instructions which have variable operands, for example, refer to the variables in terms of offsets into the allocated memory space beginning at 0

7. Loader/linkers • 3. An operating system includes a loader/linker. • This is part of the long term scheduler functionality. • When the program is placed in memory, assuming (as is likely) that its base load address is not 0, the relative addresses it contains don’t agree with the physical addresses is occupies

8. Resolving relative addresses to absolute addresses • A simple approach to solving this problem is to have the loader/linker convert the relative addresses of a program to absolute addresses at load time. • Absolute addresses are the actual physical addresses where the program resides

9. Note the underlying assumptions of this scenario • 1. Programs can be loaded into arbitrary memory locations • 2. Once loaded, the locations of programs in memory don’t change

10. Compile time address binding • There are several different approaches to binding memory access in programs to actual locations • 1. Binding can be done at compile time • If it’s known in advance where in memory a program will be loaded, the compiler can generate absolute code

11. Load time address binding • 2. Binding can be done at load time • This was the simple approach described earlier • The compiler generates relocatable code • The loader converts the relative addresses to actual addresses at the time the program is placed into memory.

12. Run time address binding • 3. Binding can be done at execution time • This is the most flexible approach • Relocatable code (containing relative addresses) is actually loaded • At run time, the system converts each relative memory address reference to a real, absolute address

13. Implementing such a system removes the restriction that a program is always in the same address space • This kind of system supports advanced memory management systems like paging and virtual memory, which are the topics of chapters 8 and 9, on memory

14. In simple terms, you see that run time, or dynamic address binding supports medium term scheduling • A job can be offloaded and reloaded without needing either to reload it to the same address or go through the address binding process again

15. The diagram on the following overhead shows the various steps involved in getting a user written piece of high level code into a system and running

17. Logical vs. physical address space • The address generated by a program running on the CPU is a logical address • The address that actually gets manipulated in the memory management unit of the CPU—that ends up in the memory management unit memory address register—is a physical address • Under compile time or load time binding, the logical and physical addresses are the same

18. Under run time/execution time binding, the logical and physical addresses differ • Logical addresses can be called virtual addresses. • The book uses the terms interchangeably • However, for the time being, it’s better to refer to logical addresses, so you don’t confuse this concept with the broader concept of virtual memory, the topic of Chapter 9

19. Overall, the physical memory belonging to a program can be called its physical address space • The complete set of possible memory references that a program would generate when running can be called its logical address space (or virtual address space)

20. For efficiency, memory management in real systems is supported in hardware • The mapping from logical to physical is done by the memory management unit (MMU) • In the simplest of schemes, the MMU contains a relocation register • Suppose you are doing run time address binding

21. The MMU relocation register contains the base address, or offset into main memory, where a program is loaded • Converting from a relative address to an absolute address means adding the relative address generated by the running program to the contents of the relocation register

22. When a program is running, every time an instruction makes reference to a memory address, the relative address is passed to the MMU • The MMU is transparent. • It does everything necessary to convert the address

23. For a simple read, for example, given a relative address, the MMU returns the data value found at the converted address • For a simple write, the MMU takes the given data value and relative address, and writes the value to the converted address • All other memory access instructions are handled similarly • An illustrative diagram of MMU functionality follows

24. Memory management unit functionality with relative addresses

25. Although the simple diagram doesn’t show it, logical address references generated by a program can be out of range • In principle, these would cause the MMU to generate out of range physical addresses • However, the point is that under relative addressing, the program lives in its own virtual world

26. The program deals only in logical addresses while the system handles mapping them to physical addresses • It will be shown shortly how the possibility of out of range references can be handled by the MMU

27. The previous discussion illustrated addressing in a very basic way • What follows are some historical enhancements, some of which led to the characteristics of complete, modern memory management schemes • Dynamic loading • Dynamic linking and shared libraries • Overlays

28. Dynamic loading • Dynamic loading is a precursor to paging, but it isn’t efficient enough for a modern environment • It is reminiscent of medium term scheduling • One of the assumptions so far has been that a complete program had to loaded into memory in order to run • Consider the alternative scenario given on the next overhead

29. 1. Separate routines of an application are stored on the disk in relocatable format • 2. When a routine is called, first it’s necessary to check if it’s already been loaded. • If so, control is transferred to it • 3. If not, the loader immediately loads it and updates its address table • An application/routine address table entry contains the value that would go into the relocation register for each of the routines, when it’s running

30. Dynamic linking and shared libraries • To understand dynamic linking, consider what static linking would mean • If every user program that used a system library had to have a copy of the system code bound into it, that would be static linking • This is clearly inefficient. • Why make multiple copies of shared code in loaded program images?

31. Under dynamic linking, a user program contains a special stub where system code is called • At run time, when the stub is encountered, a system call checks to see whether the needed code has already been loaded by another program • If not, the code is loaded and execution continues • If the code was already loaded, then execution continues at the address where the system had loaded it

32. Dynamic linking of system libraries supports both transparent library updates and the use of different library versions • If user code is dynamically linked to system code, if the system code changes, there is no need to recompile the user code. • The user code doesn’t contain a copy of the system code

33. If different versions of libraries are needed, this is straightforward • Old user code will use whatever version was in effect when it was written • New versions of libraries need new names (i.e., names with version numbers) and new user code can be written to use the new version

34. If it is desirable for old user code to use the new library version, the old user code will have to be changed so that the stub refers to the new rather than the old • Obviously, the ability to do this is all supported by system functionality

35. The fundamental functionality, from the point of view of memory management, is shared access to common memory • In general, the memory space belonging to one process is disjoint from the memory space belonging to another • However, the system may support access to a shared system library in the virtual memory space of more than one user process

36. Overlays • This is a technique that is very old and has little modern use • It is possible that it would have some application in modern environments where physical memory was extremely limited

37. Suppose a program ran sequentially and could be broken into two halves where no loop or if reached from the second half back to the first • Suppose that the system provided a facility so that a running program could load an executable image into its memory space • This is reminiscent of forking where the fork() is followed by an exec()

38. Suppose those requirements were met and memory was large enough to hold half of the program but not all of the program • Write the first half and have it conclude by loading the second half

39. This is not simple to do, it requires system support, it certainly won’t solve all of your problems, and it would be prone to mistakes • However, something like this may be necessary if memory is tiny and the system doesn’t support advanced techniques like paging and virtual memory

40. 8.2 Swapping • Swapping was mentioned before as the action taken by the medium term scheduler • Remember to keep the term distinct from switching, which refers to switching loaded processes on and off of the CPU • In this section, swapping will refer to the approach used to support multi-programming in systems with limited memory

41. Elements of swapping existed in early versions of Windows • Swapping continues to exist in Unix environments

42. This is the scenario for swapping: • Execution images for >1 job may be in memory • The long term scheduler picks a job from the input queue • There isn’t enough memory for it • So the image of a currently inactive job is swapped out and the new job is swapped in

43. Medium term scheduling does swapping on the grounds that the multi-programming level is too high • In other words, the CPU is the limiting resource • Swapping as discussed now is implemented because memory space is limited • Note that swapping for either reason isn’t suitable for interactive type processes

44. Swapping is slow because it writes to a swap space in secondary storage • Swapping can be useful as a protection against limited resources, whether CPU (medium term scheduling) or memory (swapping as described here) • However, transferring back and forth from the disk is definitely not a time-effective strategy for supporting multi-programming, let lone multi-tasking, on a modern system

45. 8.3 Contiguous Memory Allocation • Along with the other assumptions made so far, such as the fact that all of a program has to be loaded into memory, another assumption is made • In simple systems, the whole program is loaded, in order, from beginning to end, in one block of physical memory

46. Referring back to earlier chapters, the interrupt vector table is assigned a fixed memory location • O/S code is assigned a fixed location • User processes are allocated contiguous blocks in the remaining free memory • Valid memory address references for relocatable code are determined by a base address and a limit value

47. The base address corresponds to relative address 0 • The limit tells the amount of memory allocated to the program • In other words, the limit corresponds to the largest valid relative address

48. The limit register contains the maximum relative address value. • The relocation register contains the base address allocated to the program • Keep in mind that when context switching, these registers are among those that the dispatcher sets • The following diagram illustrates the MMU in more detail under these assumptions

49. MMU functionality with relative addresses, contiguous memory allocation, and limit and relocation registers

50. Memory allocations • A simple scheme for allocating memory is to give processes fixed size partitions • A slightly more efficient scheme would vary the partition size according to the program size • The O/S keeps a table or list of free and allocated memory