8.1. Memory Managementx
Download
Report
Transcript 8.1. Memory Managementx
Memory Management
Memory Management Tasks
• Accommodation of multiple processes in memory
• Memory needs to be allocated efficiently
• Allow as many processes into memory as possible.
• To fit as larger processes into memory as possible.
• Improve the overall performance of the system.
Memory Operations
• Fetch instruction from the Memory
• Operands fetching from the memory
• Store the result back into the memory
• Sometimes we can ignore how a memory address is generated
by a program.
• and be interested in only the sequence of memory addresses
generated by the running program.
How the process interacts with the
memory during its lifetime
Swapping
Relocating in
memory
Execution
Input
Queue
Swap
space
Allocating
memory
The collection of processes
waiting to be brought into
memory for execution
Process
accesses
instructions and
data from
memory
Termination
Freeing memory
Address Binding
• Most systems allow a user process to reside in any part of the physical
memory.
• Although the address space of the computer starts at 00000, the first
address of the user process does not need to be 00000.
• Addresses in the source program are generally symbolic (such as count).
• A compiler will typically bind these symbolic addresses to relocatable
addresses (such as "14 bytes from the beginning of this module").
• The linkage editor or loader will in turn bind these relocatable addresses
to absolute addresses (such as 74014).
• Each binding is a mapping from one address space to another.
How the binary code could be relocatable ?
recall
.text 0x00400000
x:
value:
a:
.globl main
. . .
.data 0x10010000
.word
4
.word
1
.word 20
Code could be
relocatable because
this address forming is
relative
However the whole code is not
relocatable because this
address forming is absolute. We
need to recompile for
relocation.
Address Binding at compile time
Binary code is different (non relocatable)
Code could be relocatable
because this address
forming is relative
However the whole code is not
relocatable because this address
forming is absolute. We need to
recompile for relocation.
.text 0x00420000
.data
.globl main
x:
.word
absolute
.• . If. the instructions contain
value:
.word
a: is not
.word
addresses then that code
bb:
.word
relocatable.
0x10020000
4
1
20
-2
• To make the code relocatable the
compiler should use only relative
addresses based on some base register(s)
value.
Address Binding at link time
Load Module (Executable File)
Header (parameters and a small program loader)
-----------------------------------------------0040 0000
Object Module 1
Variable 1
Subroutine 1()
Other Subroutines ...
Load Address
Variable2
Jal Subroutine2
0040 1000
Object Module 2
AddressV2
AddressS2
Other Subroutines ...
----------------------------------------------------------------------Variable2
Subroutine 2()
Other Subroutines ...
Load Address
Variable 1
Jal Subroutine 1
AddressV1
AddressS1
Other Subroutines ...
Object Modules can be relocatable
But the linker can bind the module addresses to the absolute addresses
Address Binding
Address binding
could be done at
(code becomes
not relocatable)
Compile time: If you know at compile time
where the process will reside in memory, then
absolute code can be generated. If, at some
later time, the starting location changes, then it
will be necessary to recompile this code.
Static Link time: . . .
Address binding could be
done at static link time
(code should be compiled
as relocatable)
Address binding
could be done at
(code should be
compiled and linked
as relocatable)
Address binding
could be done at
Address binding could
be done at dynamic link
time
(needs special
hardware)
Load time: If it is not known at compile time
where the process will reside in memory, then
the compiler must generate relocatable code.
In this case, final binding is delayed until load
time. If the starting address changes, we need
only to reload the user code to incorporate this
changed value.
Execution time: If the process can be moved
during its execution from one memory
segment to another, then binding must be
delayed until run time. Special hardware must
be available for this scheme to work. Most
general-purpose OS use this method.
Dynamic Link time: . . . (again run time)
How many relocation
registers
we need for 3
Logical Versus• Physical
Address
Space
processes running concurrently on one CPU?
•
an address generated by the CPU is commonly referred to as a logical address (virtual
address)
•
whereas an address seen by the memory unit is commonly referred to as a physical
processes running on two CPUs?
address.
• How many relocation registers we need for 3
•
Logical Address
Space
000
...
346
...
500
000000
Virtual
Address
Physical
Address
Space
14000
...
•
14500
•
FFFFFF
Base or relocation register scheme
000 - 500
R+000 .. R+500
•
The set of all logical
addresses generated by a
program is a logical-address
space
The set of all physical
addresses corresponding to
these logical addresses is a
physical-address space.
Thus, in the execution-time
address-binding scheme, the
logical- and physical-address
spaces differ.
The run-time mapping from
virtual to physical addresses
is done by a hardware device
called the memorymanagement unit (MMU)
Memory Protection
The goals
• The operating system should be protected from access by user processes
• User processes should be protected one from another
How to implement
•
We first need to make sure that each process has a
separate memory space
•
and can access only that memory space
•
we need the ability to determine the range of
legal addresses
•
•
We can provide this protection by using two
registers, usually a base and a limit
•
The base register holds the smallest legal
physical memory address;
•
the limit register specifies the size of the
range
This protection must be provided by the hardware.
Memory Protection Hardware
•
•
•
•
•
•
hardware compares every address generated in user mode with the registers.
Any attempt by a program executing in user mode to access operating-system
memory or other users' memory results in a trap to the operating system, which treats
the attempt as a fatal error.
This scheme prevents a user program from (accidentally or deliberately) modifying
the code or data structures of either the operating system or other users.
The base and limit registers can be loaded only by the operating system, which uses a special
privileged instruction.
The operating system, executing in kernel mode, is given unrestricted access to both operating
system memory and users' memory.
This provision allows the operating system to load users' programs into users' memory, to dump out
those programs in case of errors, to access and modify parameters of system calls, and so on.
Memory Protection
and
Relocation
Hardware
• How
many
relocation and limit
registers we
•
need for 3 processes running concurrently on
With relocation and limit registers one CPU?
•
•
•
each logical address must be less than the limit register;
the MMU maps the logical• address
dynamically
by adding
value
in the we
How many
relocation
and the
limit
registers
relocation register. This mapped address is sent to memory
need for 3 processes running on two CPUs?
When the CPU scheduler selects a process for execution, the dispatcher loads the
relocation and limit registers with the correct values as part of the context switch.
• Can the user program change the relocation
and limit registers values to access the
74600
Max logical physical storage wherever it needs?
address
0-74600
100040
100040
100145
105
100040 + 74600
Dynamic Loading
Loading of some modules or libraries is being postponed until their
execution time.
•
•
•
•
Routine is not loaded until it is called
Better memory-space utilization; unused routine is never loaded.
Useful when large amounts of code are needed to handle infrequently occurring
cases.
OS not involved in the modules organization. The user program is responsible for it.
So module sharing between different protected processes is not possible
Symbol
Table
Common
Routines
Linked final
binary module
Module
1
Linked final
binary module
Relocatable
loader
Modules are not loaded
until they are called
Module
2
Dynamic Linking and Shared Libraries
Rather than loading being postponed until execution time, linking is postponed.
OS involved in the modules organization. So module sharing between different protected
processes is possible. This is shared libraries approach.
Static Linking
Dynamic Linking
Main
modules
of
Program1
Main
modules
of
Program2
Main
modules
of
Program3
Statically
linked
Library1
Statically
linked
Library1
Statically
linked
Library1
Statically
linked
Library2
Statically
linked
Library2
Statically
linked
Library2
Main
modules
of
Program1
Main
modules
of
Program2
Main
Not finally linked
modules binary modules
of
Program3
Dynamically
Linked
Library1
Not finally linked
binary modules
Dynamically
Linked
Library2
Final binary code
is formed by
linking at runtime
when the library is
called
Advantages of DLL
Fast loading of the main module and of the modules needed at this moment
Saving resources using one library instead of many
Modular architecture
Flexibility of module update
Disadvantage: The sharing of the same library between different processes and the
frequent updates cause version conflict and complexity of update implementation.
Swapping
• A process needs to be in memory to be executed.
• A process, however, can be swapped temporarily out of memory to a backing
store
• and then brought back into memory for continued execution
• Normally a process that is swapped out will be swapped back into the same
memory space that it occupied previously.
• If binding is done at assembly
or load time, then the process
cannot be moved to different
locations.
• If execution-time binding is
being used, then a process can
be swapped into a different
memory space, because the
physical addresses are
computed during execution
time.