Virtual Memory

1. Operating Systems: Virtual Memory Virtual Memory • Physical Addressing • addresses generated in the CPU by the running program used directly to address main memory • Virtual Addressing • addresses generated in the CPU are mapped into different physical addresses • why? Problems with Physical Addressing Problem 1 : Not enough main memory • software ever larger e.g. Microsoft products • bloatware • data ever larger e.g. high-resolution images and video, databases • servers servicing a large community of users – web servers, compute servers • even though memory prices much cheaper than previously, never enough!

2. Operating Systems: Virtual Memory Overlays • historically used to overcome memory size limitations • not all of the program and its data in memory at once • just those parts currently running and needed • Example: a multi-pass compiler • each pass processes whole program • pre-processor e.g. macros in C • Syntax analysis • semantic analysis • optimisation • code generation • an area of memory usedfor each successive pass • code for each pass storedon disc Symbol table Common procedures Overlay driver Area for code of successive passes Pass 2 Pass 1

3. Operating Systems: Virtual Memory • Overlays as branches of a tree: • Multi-level overlays: • e.g. IBM JCL for Fortran • specified by programmer in terms of his subroutines • user might know best but inconvenient • compiler could work out overlay structure automatically • dynamically with a learning system? Pass 1 Pass 2 Pass 3 Pass 4 Pass 5 a c b a d a e b f d e f g b g h b g i h i c

4. Operating Systems: Virtual Memory Multiprogramming • running several programs on one CPU concurrently • control passed between programs whenever one is held up e.g. for I/O • makes more efficient use of the CPU • may not be enough main memory to hold all the programs at once • need to swap programs to and from disc to make room • swapping inefficient – delays, overheads, channel usage etc. • faster discs with more cache only alleviate, not cure Operating System Program 1 User Program Space Program 2

5. Operating Systems: Virtual Memory Problem 2 : Relocation • where in memory will the program be loaded? • what program counter and data addresses will be used as the program runs? • Absolute code: • program code with fixed addresses built into it: • will only run at that position • might just be OK for system with no multi-tasking e.g. MS-DOS • compilers need to know exactly where the code they generate will be loaded • very inconvenient in a multi-programming system: • compiler needs to know which partition program will be loaded into • even more difficult for systems with dynamic partition boundaries • 100 LD R1, 121101 ADD R1, 122102 ST R1, 123. . . . . . . .110 BR 100. . . . . . . .121 .word 12345122 .word 54321123 .word 0. . . . . . . . Op. Sys. Partition 1 Partition 2 Partition 3

6. Operating Systems: Virtual Memory • 0 LD R1, 21 1 ADD R1, 22 2 ST R1, 23 . . . . . . . .10 BR 0 . . . . . . . .21 .word 1234522 .word 5432123 .word 0addresses: 0, 1, 2, 10 • Relocatable code: • compiler generates codes as if it were to run at address 0 • plus a list of places where addresses are present in the code • a relocating loader modifies the code after it has been loaded • adds the load address to every place where there is an address in the code • example loaded at address 1000 in memory would produce: • code is executed at that position • cannot be moved anywhere else • 1000 LD R1, 1021 1001 ADD R1, 10221002 ST R1, 1023 . . . . . . . .1010 BR 1000 . . . . . . . .1021 .word 123451022 .word 543211023 .word 0

7. Operating Systems: Virtual Memory • a linking loader combines linking several program components together and loading them into memory • library components, separately compiled units etc. • each module compiled relative to address 0 • each module relocated to correct address • cross-links between modules organised • statically linked code i.e. linking done at load time • alternative is to load and link dynamically when a module is first called • remaining problems: • relocated code must always be placed at the same fixed address, even when swapped out to disc and back! • care still needed for addresses within data – need to use relocated addresses • sharing code between programs i.e. only one copy in memory • cannot be linked into both code images – need to be somewhere separate module 1 module 2 module 3

8. Operating Systems: Virtual Memory • Self-relocating code: • code which will run anywhere in memory without modification • usually involves the compiler generating code in which effective addresses are all relative to some register contents • example IBM 360/370/380/390: LD R1, 123(R4, R15) • load R1 from address 123+(R4)+(R15), i.e. double indexing • use R15 to index all addresses • now ensure R15 contains load address of program: BALR R15, 0 • a dummy ‘branch and link’ which stores address of next instruction i.e. the ‘return’ address but does not branch • a relocating loader not now needed, but a linker still needed for separately compiled modules • together with coding standards to ensure all modules use the same register indexing conventions • once code has started running, it cannot be moved e.g. after swapping • still needs care with data addresses e.g. pointers must be relocated somehow

9. Operating Systems: Virtual Memory • Position-independent code: • code which can run at any address without modification • typically uses program counter relative branches: 100 LD R1, 121 . . . . 110 BR * - 10 . . . . • sometimes different instructions for short and long distance branches • e.g. Intel x86 JMP instruction, 8, 16 or 32 bit relative (intra segment jump) • in principle could move code to another place in memory e.g. after a swap • just need to modify the PC once for the new load address • but still can’t move data around – incorrect pointer values • ideally need a system which allows code and data to be separate • loaded into different memory areas which can be dynamically changed • not possible in Linux – an executable is a single image of code and data • but static and dynamic sharing of library code possible

10. Operating Systems: Virtual Memory • Re-entrant code: • code which can be used by more than one process or thread concurrently • each will have its own program counter, registers etc. • each will have its own data areas e.g. stack • also known as thread-safe code • thread-safe sharable libraries often needed • needs to be unmodified by any relocating loader i.e. self-relocating • usually needs to be position independent • in a virtual memory system, allows code to be at different addresses in each process • code placed in a separate area of memory from non-shared code • needs to be linked to other modules indirectly • probably via a separate data area in each process • may well have different other modules for each process • must not modify the shared code itself

11. Operating Systems: Virtual Memory • Dynamic linking: • modules loaded and linked at run-time when first called • useful for large packages where few facilities used at any one time • Emacs, MS Office, Photoshop etc. • just load those parts that are used and not all of it • compiler generates code for a procedure call which branches to a loader instead of the procedure entry point: LD R1, “procedure-name” BALR R2, loader-entry-point . . . . • the loader loads the module containing the procedure and links it in by modifying the calling code to: LD R1, R1 BALR R2, procedure-entry-point • next and subsequent procedure calls go straight to the linked module • not satisfactory when re-entrant code required

12. Operating Systems: Virtual Memory • Indirect dynamic linking (Arden, Galler et al.) : • each compiled module has a General Linkage Area Pattern (GLAP) which contains references to all the external objects it uses: • each reference placed at a fixed relative address to start of GLAP • compiled code uses addressing relative to a register fixed by call protocol • code and GLAP are execute read-only • when a module is loaded, its GLAP is copied into a General Linkage Area (GLA) in a separate area of memory: • references to external objects remain at same position relative to start of GLA • GLA is writable and unshared i.e. one per process re-entrant code GLAP other GLAs GLA other GLAs

13. Operating Systems: Virtual Memory • for procedures to be loaded statically: • loader modifies the reference in the GLA to give the procedure’s actual address • the GLAP remains unchanged • branches to external procedure use indirect addressing relative to the GLA • call protocol to ensure that base address of the GLA is in the correct register • for procedures to be loaded dynamically: • the static loader places the address of the dynamic loader in the GLA position for the external reference • together with the external procedure name • when procedure first called, dynamic loader entered • loads required procedure module • modifies GLA reference to point directly to newly loaded procedure • branches indirectly to procedure • and on all subsequent calls • demonstrates the need for separate areas of memory to be available • and with possibly different level of access permission

14. Operating Systems: Virtual Memory ELF : Executable and Linking Format • the standard object file format for Linux • portable over UNIX systems • offers parallel views of a file’s contents: • a linking view and an execution view • sections hold information on instructions, data, symbol table, relocation data etc. • gets quite complex: Linking View Execution View ELF Header ELF Header Program header table Program header table Section 1 Segment 1 . . . . . . . . Section n Segment n . . . . . . . . Section header table Segment header table

15. Operating Systems: Virtual Memory ELF decode of : decodeExecutable fileIntel 80386Entry point 80484905 program header entries :program hdr table info : at 0x34interpreter path : at 0xd4loadable segment : file image size = 0x1452 : memory image size = 0x1452 : at 0x0loadable segment : file image size = 0xcc : memory image size = 0xd0 : at 0x1458dynamic link info : at 0x149c23 sections present : : inactive : unknown flag at 0x0, size 0x0 : .interp : program defined info : occupies memory at 0xd4, size 0x13 : in memory image at 0x80480d4 .hash : hash table : occupies memory at 0xe8, size 0xa0 : in memory image at 0x80480e8 .dynsym : dynamic symbol table : occupies memory at 0x188, size 0x150 : in memory image at 0x8048188 .dynstr : string table : occupies memory at 0x2d8, size 0xb8 : in memory image at 0x80482d8 .rel.bss : relocation entries without addends : occupies memory at 0x390, size 0x8 : in memory image at 0x8048390 .rel.plt : relocation entries without addends : occupies memory at 0x398, size 0x48 : in memory image at 0x8048398 .init : program defined info : unknown flag at 0x3e0, size 0x8 : in memory image at 0x80483e0 .plt : program defined info : unknown flag at 0x3e8, size 0xa0 : in memory image at 0x80483e8 .text : program defined info : unknown flag at 0x490, size 0xaa0 : in memory image at 0x8048490 .fini : program defined info : unknown flag at 0xf30, size 0x8 : in memory image at 0x8048f30 .rodata : program defined info : occupies memory at 0xf38, size 0x51a : in memory image at 0x8048f38 .data : program defined info : unknown flag at 0x1458, size 0x4 : in memory image at 0x804a458 .ctors : program defined info : unknown flag at 0x145c, size 0x8 : in memory image at 0x804a45c .dtors : program defined info : unknown flag at 0x1464, size 0x8 : in memory image at 0x804a464 .got : program defined info : unknown flag at 0x146c, size 0x30 : in memory image at 0x804a46c .dynamic : dynmic link info : unknown flag at 0x149c, size 0x88 : in memory image at 0x804a49c .bss : no space : unknown flag at 0x1524, size 0x4 : in memory image at 0x804a524 .comment : program defined info : unknown flag at 0x1524, size 0x3a : .note : mark info : unknown flag at 0x155e, size 0x3c : in memory image at 0x3a .shstrtab : string table : unknown flag at 0x159a, size 0xa0 : .symtab : symbol table : unknown flag at 0x19d4, size 0x410 : .strtab : string table : unknown flag at 0x1de4, size 0x184 :

16. Operating Systems: Virtual Memory Problem 3 : Protection • read, write, and execute access to memory • hardware controls • not file-access controls • read-only : memory cannot be written to • protects against inadvertent over-writing • read-access usually allows execution also – ideally should be separate • execute-only : code can be executed • access to authorised users only • ideally should not allow read-access • protects proprietary code against copying • write-access : usually allows read-access also • append permission would also be useful • no-access : private memory areas • operating system, kernel areas etc. • direct-mapped I/O areas, interrupt tables etc.

17. Operating Systems: Virtual Memory Op. Sys. Partition 1 Partition 2 Partition 3 • other partitions in a multiprogramming or multi-tasking system: • degree of granularity of protection: • fixed size areas • 4096 byte pages? • every byte? • variable size areas • large blocks of memory e.g. 65536 byte segments • smaller areas e.g. transactions, database records etc. • rings of protection: • code with higher privilege has more access to memory than code with lower privilege • kernel, sub-systems, applications, user code higher lower higher lower

18. Operating Systems: Virtual Memory Problem 4 : Efficiency of memory usage • in a multiprogramming system: contiguous areas needed • fixed partitions: • variable size, arbitrary positions: • gets worse as program start and finish: Op. Sys. Partition 1 Partition 2 Partition 3 waste space – internal fragmentation waste space – external fragmentation Op. Sys. Program 1 Program 2 Program 3 Op. Sys. P1 P4 P3 Op. Sys. P1 P4 P5 Op. Sys. P6 P4 P5 Op. Sys. P6 P4 P7 P8 P9 Op. Sys. P6 P4 P7 P9

19. Operating Systems: Virtual Memory • individual areas too small although total unused may be big enough • compaction may or may not be possible • not possible if code relocated to a fixed address • when possible, could shuffle areas down to bottom (or top, or both): • when and how often to do compaction? • which areas to move to minimise amount of copying? • problem: a program’s memory requirements change as time progresses • stacks expand and contract • other data areas needed unpredictably • new code modules dynamically loaded • need contiguous areas • need to leave gaps of sufficient space for any eventuality • wasteful of space • would like some system which allows separate areas to grow as required without any inefficiency Op. Sys. P6 P4 P7 P9

20. Operating Systems: Virtual Memory Problem 5 : Modularity and Sharability • Distinct areas needed for various reasons: • multiprogramming, dynamic linking, protection, memory efficiency etc. • also for modular code • separate compilation - each unit compiled as a separate entity • object orientation e.g. each Java class compiled separately • also separate data e.g. files • may need varying access control for each module • Sharability: • for libraries and common applications • editors & compilers, spreadsheets etc. • sharing in memory more efficient • saves disc transfers – hence better response time • very difficult to share unless separate memory areas used • Used extensively in EMAS: • main reason for needing to overallocate pages • all pages demanded counted against each user – even if shared

21. Operating Systems: Virtual Memory • need an architectural mechanism that provides distinct areas for modules • with ability to grow and shrink without loss of efficiency • a 2-dimensional view of memory rather than 1-dimensional