Operating Systems Course  - 203.2110

Spring 2005

Zvi Yehudai 

 

Main

Syllabus

Staff

Schedule

Class Material

Drill Page

Project

 

Call for Project Teams

 

Here is the final list of project teams. Blue names are those scheduled by me.

 

Last

First

Group

GAL

TOMER

1

RAMRAZ

ODED

BEN-SHABAT

ORI

2

COHEN

ERAN

BRILL

LIOR

3

SHAMIR

YANIV

STOLLAR

ITAMAR

ABED-ILHADE

MOHAMED

4

NAJJAR

ASHRAF

YASSIN

MAHMOOD

BLITSHTEYN

MICHAEL

5

SAGGIE

GAL

BAR

MICHA

6

GOLDNER

DAN

WOLLOCH

URI

7

MENDELSSOHN

NOAM

ABAYA

YACOUB

8

SHAHIN

KHALIL

SHEKH ALIH

MUHAMAD

BOYMEL

GIL

9

HENDIN

ILAI

FRIEDMAN

BEN

10

LEWIN

OMRI

HADDAD

GEORGE

11

MOHANNA

ISAEED

OREN

OFIR

12

PACHTER

RON

FARRAN

ISSAM

13

KAWAR

AMEER

OZ

NADAV

ABBOUD

FADI

14

ISSA

FRIDA

KETANY

MOHAMED

BROSTOVSKY

OR

15

INDIG

YISSAKHAR

ROSEN

ADY

DAHAN

SHARON

16

EBENSTEIN

ASAF

ROGINSKY

YEKATERINA

BEN YEHOSHUA

MICHAL

17

EREL

SAGI

YASHAEV

SIMON

HANDLER

ITAI

18

HEILPER

DANIEL

SEGAL

SAGI

EDRI

HAIM

19

GAZINSKY

AYALA

MARKOVITCH

SAGI

CURI

SHRON

20

LEVI

MOSHE

NANIKASHVILI

MOTI

BOLSHEM

BORIS

21

BURSTEIN

ALEXEY

PLOTKIN

LEV

 

 

 

 

Memory Manager


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