Abstract
Memory
management is one of the central roles of the operating system. A memory
management unit is responsible for several key functionalities, such as:
allocating memory for processes, translating virtual addresses to physical
ones, handling page faults etc. In addition, a good memory manager performs
garbage collection, memory allocation compactions and, in general, uses
much less resources from the operating system then required by the
processes it serves.
We have
explored several methods of memory management, from physical memory to
virtual memory. We noted that virtual memory allows processes to relate to
the same logical addresses without the need to compute physical ones. Also,
we mentioned that the operating system divides the physical (logical)
memory to frames (pages) of fixed size.
Description
You need
to implement a Memory Manager which will provide the following
functionality:
ð
Allocating
memory to processes when required.
ð
Enables
memory-read and memory-write capabilities to the processes.
ð
Handle
page faults.
ð
Maintains
the following statistics:
o
Physical
memory usage (average / stdev / peak)
o
Logical
memory usage (average / stdev / peak)
o
Page
faults rate (per sec)
o
I
might add additional statistics later on
o
You
may think of additional statistics to be shown
ð
Performs
garbage collection.
ð
Imposing
the limits set by the user on the processes. For example, imposing the
physical memory limit (see below) means replacing allocated pages (paging).
The Memory
Manager will use a configuration file with the following definitions /
information:
ð
Physical
Memory Limit (PML) – maximum number of bytes that can be allocated by the
manager out of physical memory.
ð
Backing
Store Limit (BSL) – maximum number of bytes that can be stored on the file
system. You should store on the file system pages that don’t reside in
physical memory. When there is no more space available both in physical
memory and in the backing store, an OUT_OF_MEMORY error should be
returned by any process that attempts to allocate memory.
ð
Frame
Size (FS) – the frame size you should work with. You can assume that PML
and BSL both divide FS.
ð
Output
File (OF) – a fully qualified file name that should store the output of a
run.
ð
Debugging
level (0 – no debug, 1- partial debug, 2- full debug)
The Memory
Manager will use the following APIs (the exact signature of each will
appear in the header file):
ð
ProcessStart
/ ProcessEnd – indicates start / end of a process. A process is given a
process id (pid) with which it is identified by the Memory
Manager.
ð
AllocateMemory -
returning an object that contains information about the allocated
object (see below) such as the object’s ID.
ð
Read / Write memory object.
ð
Lock
/ Unlock memory object.
ð
De-allocate
a memory object.
ð
Additional
APIs might be added later on
Implementation
You will
implement your Memory Manager in C++ and wrap the implementation in
a DLL. The methods that will be exposed by the DLL will be defined by a
header file that will be provided.
To
emulate several processes, you will be given a main which creates
several threads, each trying to allocate, access, read and write to/from
memory via calls to the Memory Manager functions. Thus your
implementation of the Memory Manager needs to be multi-thread safe.
You are also
required to provide a design document of your project. The design document
must detail at least the following:
ð Page replacement algorithm – data
structures and time complexity analysis.
ð Garbage collection method used –
when and how often is garbage collection performed.
ð Memory management scheme – how is
the memory of each process managed (page tables, inverted page tables
etc.).
ð The metadata stored for each
process (such as page access information).
ð Backing store structure.
ð
A
sequence diagram (such as a flow chart) of:
§
Page
fault handling
§
Read
/ Write from memory
§
Memory
allocation
§
Process
Start / End
Submission
The
project’s submission date is 17-June-2005
The
project will be submitted in the following structure:
ð A “src” folder which
contains the source code (header files, cpp files and Visual Studio’s
files).
ð A “bin” folder which
contains the executable and DLL files.
ð
A
“config” folder which contains the Memory Manager’s
configuration file.
ð
A
“docs” folder which contains the output file and your project design
document.
Grading
Your
project grade (which will be 25% - 30% of your final grade) will be based
on
ð
Implementation
(correctness, style, documentation)
ð
Report
(experiments, conclusions, presentation)
ð
Defending
your project – i.e. I will meet the group members and will ask all kinds of
irritating questions
ð
It
is also expected to test the solution online by feeding it input during
defense session
Project Files
memmgr.h
memobject.h
|