Virtual memory Flashcards
Why processes need memory
Every process needs memory for:
- Instructions (“code” or”text” segments)
- Static data (in program - not changing)
- Dynamic data (heap and stack)
- AND memory for OS instructions and data
- Multiprogramming system has many processes in memory simultaneously
Issue of relocation
- Sharing => programmer no longer knows runtime address of process on a specific machine / other processes.
- Swapping running/waiting processes into / out of memory to reuse space for other processes => silly to require swapped process to always go to same place in memory after being swapped back from HDD. Irritating constraint…
- Process may incorporate addresses (branching, pointers) and OS must sanity check the logical addresses generated by the process, without confusion e.g. process branching to instruction in another process’s address space.
Conclusion : need to translate LOGICAL (program generated) to PHYSICAL addresses (machine dependent). OS manages translation.
Issues of allocation
Where does the OS put the process in memory? How does it find a large enough chunk of memory so that the process can do something useful. No use loading half the process into memory - not all instructions / data.
- OS has to place data/ instructions in memory to make linking or relocation easier
- Related to sharing
Issues of protection
Multiple processes in memory
- Ensure a given process cannot interfere with the memory of another process.
- One process should not be able to write the memory of another process unless under specific circumstances e.g. communication, OS needs to prevent accidental accesses (e.g. buggy processes).
(Protection between processes)
1. OS needs to protect one process from others
(RWX protection)
2. OS may implement RWX protection on small memory units - designate readable / writable / executable chunks of memory.
(Self modifying code - malware target)
3. OS should prevent process modifying its own code (why - confusing, bugs, possibility to attacks/malware. If the OS knows that the program’s instructions CANNOT be changed while it executes, then nobody can try and change that to inject bad instructions. )
(Dynamically generated addresses)
4. OS should sanity check dynamically computed addresses (e.g. array subscripts) - ensure that invalid memory is not accessed (e.g. EDSAC … sparse instruction set => fails fast, most bit patterns not valid instruction, fails near bug).
Issues of sharing
Efficiency argument
- Multiple processes executing same binary - would like to keep only one copy in memory.
- Data can be shipped between processes by passing shared data segment references
- Operating on same data concurrently requires sharing locks with other processes.
- OS has to multiplex memory in a reasonably fair way
Issues of logical organisation
(Physical memory)
- Physical memory : linear address space from 0 to max.
But,
(Contrast between physical memory and programmer view of memory)
2. Physical memory doesn’t correspond to modular structure of programs : want segments.
(Modules - locating modifiable data and code which modifies it)
Previously was useful to structure process into modules.
3. Modules can contain modifiable data or just code - locate modifiable data with data that can modify it - reduces chance of unwarranted modification.
(Independently compiled modules)
4. Would be useful if the OS could deal with modules, written and compiled independently.
(Protection and sharing of modular units of code rather than whole process data)
5. Can give different modules different protection and can be shared, thus easy for user to specify sharing model.
e.g. put heap in one segment, make it readable / writable to facilitate IPC
But, put stack and instructions / static data
in another segment and make it non-readable / non-writable
Specificity ???????
issues of physical organisation
There is a storage hierarchy …
- Main memory - single linear address space, volatile, more expensive
- Secondary storage : cheap, non-volatile, can be arbitrarily structured.
- OS should organise flow between main memory and secondary store (buffering using a cache - need to manage what should be kept in the cache).
- Programmer may not know beforehand how much space will be available.
- Programmer does not want to deal with cache associativity, 4-way / 2-way, etc… complexity - would like OS to abstract away the cache and management.
What is the address binding problem
- Logical variables and data are compiled to addresses in assembly code - contain relocatable addresses passed to instructions e.g. LOAD, STORE, ADD … which take memory address arguments.
- Problem : What physical addresses do you assign the abstract memory locations in the compiled code?
cannot assign addresses before loading, because compiler does not know where in memory the program will be loaded (otherwise would know where the program would be loaded, specify offset from loading address for each required memory location).
Conclusion : translate between program addresses and real addresses
Outline solutions to address binding problem
Solution : translate between program addresses and real addresses.
Can be done at
1. Compile time (simple but very old systems)
- Load time : Load code, find the position it was put into memory by the OS, OS fixes up references.
- Run time
Evaluate : address binding at compile time
- Requires knowledge of absolute addresses (e.g. DOS .exe files).
Evaluate: address binding at load time
- Find position in memory after loading, update code with correct addresses
- Must be done every time program loaded
- OK for embedded systems (processes run forever) / boot loaders (once at start of day)
Evaluate: address binding at run time
Perform relocation as the program is executing
- Hardware automatically translates between program and real addresses.
=> Need hardware support : too slow with software because have to translate EVERY logical address generated by CPU / every variable access … - No changes required to program itself
- Given MMU hardware - the most popular and flexible scheme.
- Hardware support also nice because reduces complexity of memory management software / transparent to programmer / MMU can be hardware specific removing need for OS to consider platform-dependent parameters.
MMU purpose
Memory management unit,
MMU, maps logical to physical addresses at run time.
MMU - how relocation occurs (scheme:= base relocation, simple system)
CPU generates logical addresses
MMU converts those to physical addresses.
- Relocation register holds value of base address owned by process
- Relocation register contents are added to each memory address before sent to main memory
- Instruction may reference some areas in memory - control bits to memory / IO bus (recap buses) - hardware enters data from bus into CPU registers, available to process. - e.g.MS DOS on 80x86 - 4 relocation registers, logical address is a tuple (segment, offset)
- Process never sees physical address, simply manipulates logical addresses
- OS has privilege to update relocation register : guarantees process cannot access memory it is not allowed to do so by OS (limit register - how far it can go through memory).
- Diagram CPU =LA=> MMU => PA => MM, or translation fault to OS.
- If no corresponding memory location exists, a translation fault / hardware exception sent to OS, OS catches the fault, OS works out what to do e.g. location of an object may have changed, update segmentation table.
Problem of contiguous allocation
How do we support multiple virtual processors in a single
address space?
Where do we put processes in memory?
