Presentation is loading. Please wait.

Presentation is loading. Please wait.

Operating Systems: Virtual Memory 1 Virtual Memory Physical Addressing – addresses generated in the CPU by the running program used directly to address.

Similar presentations

Presentation on theme: "Operating Systems: Virtual Memory 1 Virtual Memory Physical Addressing – addresses generated in the CPU by the running program used directly to address."— Presentation transcript:

1 Operating Systems: Virtual Memory 1 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 2 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 used for each successive pass –code for each pass stored on disc Symbol table Common procedures Overlay driver Area for code of successive passes Pass 1 Pass 2

3 Operating Systems: Virtual Memory 3 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 d a e b f b g h b g i c a c b d e f g h i

4 Operating Systems: Virtual Memory 4 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 User Program Space Program 1 Program 2

5 Operating Systems: Virtual Memory 5 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 100LDR1, 121 101ADDR1, 122 102STR1, 123........ 110BR100........ 121.word12345 122.word54321 123.word0........ Op. Sys. Partition 1 Partition 2 Partition 3

6 Operating Systems: Virtual Memory 6 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 0LDR1, 21 1ADDR1, 22 2STR1, 23........ 10BR0........ 21.word12345 22.word54321 23.word0 addresses:0, 1, 2, 10 1000LDR1, 1021 1001ADDR1, 1022 1002STR1, 1023........ 1010BR1000........ 1021.word12345 1022.word54321 1023.word0

7 Operating Systems: Virtual Memory 7 –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 8 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: LDR1, 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: BALRR15, 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 9 Position-independent code: –code which can run at any address without modification –typically uses program counter relative branches: 100LDR1, 121.... 110BR* - 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 10 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 11 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: LDR1, “procedure-name” BALRR2, loader-entry-point.... –the loader loads the module containing the procedure and links it in by modifying the calling code to: LDR1, R1 BALRR2, 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 12 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 13 –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 14 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 ELF Header Program header table Section 1.. Section n.. Section header table Execution View ELF Header Program header table Segment 1.. Segment n.. Segment header table

15 Operating Systems: Virtual Memory 15 ELF decode of : decode Executable file Intel 80386 Entry point 8048490 5 program header entries : program hdr table info : at 0x34 interpreter path : at 0xd4 loadable segment : file image size = 0x1452 : memory image size = 0x1452 : at 0x0 loadable segment : file image size = 0xcc : memory image size = 0xd0 : at 0x1458 dynamic link info : at 0x149c 23 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 : 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 : 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 16 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 17 »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 Op. Sys. Partition 1 Partition 2 Partition 3 higher lower

18 Operating Systems: Virtual Memory 18 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 Op. Sys. Program 1 Program 2 Program 3 waste space – external fragmentation 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 19 –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 20 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 21 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

Download ppt "Operating Systems: Virtual Memory 1 Virtual Memory Physical Addressing – addresses generated in the CPU by the running program used directly to address."

Similar presentations

Ads by Google