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!

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 usedfor each successive pass

–code for each pass storedon disc

Symboltable

Commonprocedures

Overlaydriver

Area for codeof successive

passes

Pass 1 Pass 2

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

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

OperatingSystem

UserProgramSpace

Program 1

Program 2

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

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

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

0 LD R1, 21 1 ADD R1, 22 2 ST R1, 23 . . . . . . . .10 BR 0 . . . . . . . .21 .word 1234522 .word 5432123 .word 0

addresses: 0, 1, 2, 10

1000 LD R1, 1021 1001 ADD R1, 10221002 ST R1, 1023 . . . . . . . .1010 BR 1000 . . . . . . . .1021 .word 123451022 .word 543211023 .word 0

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

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:

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

Operating Systems: Virtual Memory

9

•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

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

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:

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, R1BALR R2, procedure-entry-point

–next and subsequent procedure calls go straight to the linked module

–not satisfactory when re-entrant code required

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

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

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

Operating Systems: Virtual Memory

15

ELF decode of : decode

Executable fileIntel 80386Entry point 8048490

5 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 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 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 :

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.

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

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

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

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

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