COP4610 - Fall 1997 - P4 - Fourth Programming Assignment

Objective(s)

  1. Learn about the implementation details of virtual memory.

Deadlines and Deliverables

E-mail a copy of your modified JavaOS files complete with a journal to cop4610@cs.fsu.edu, by Friday, November 21st at midnight.

The method for emailing your solution is to create a uuencoded compressed tar image of only the files you changed. This way the grader can just uudecode, uncompress, and un-tar your files on top of an unmodified JavaOS source tree and your files will drop into place for easy grading. For example, assuming that you modified the files SOSSyscallIntHandler.java and AppTests.java, then you would turn in your assignment like this (substitute "tar" for "gnutar" if you are on a Linux machine):

cd
cd cop4610/P4
gnutar czvf ~/P4.tar.gz SOSSyscallIntHandler.java AppTests.java P4.journal
cd
chmod 700 P4.tar.gz
uuencode P4.tar.gz < P4.tar.gz 
      | /usr/ucb/mail -s "P4 submission" cop4610@cs.fsu.edu

Don't forget to include your journal file in the tar file!

Grading

This project will be graded on a scale of 0-100.

Getting Started

The following steps will install an entire working copy of the JavaSOS simulator into your home directory and build the simulator from the source code. Notice that you probably already have a "cop4610" directory (or equivalent) so all these steps may not be necessary. Also notice that this assignment uses a different JavaSOS starting source file from the previous assignments.

cd
mkdir cop4610
chmod 700 cop4610
cd cop4610
mkdir P4
chmod 700 P4
cd P4
gnutar xzvf ~jtbauer/jsosP4.tar.gz
make

To run the simulator, do the following:

java SIM

The simulator will run as described in the Guide to the Java Version of SOS available in class and from the class home page. A text file named sim.out is created that contains all the trace messages from the simulation run.

Assignment

Your assignment is to extend JavaSOS to support a paged virtual memory subsystem.

Given

The P4 version of JavaSOS has already been partially modified for this assignment. In particular, AppTests.java contains a new test that demonstrates two new memory calls, WriteMem() and ReadMem(). The complete simulation of virtual memory for code and data within JavaSOS is not possible, since the actual context and memory management of the Java threads that underly the JavaSOS processes happens within the Java Virtual Machine. The existing JavaSOS memory structure, using arbitrary Java objects, is too cumbersome to deal with so yet another memory abstraction was created for this assignment. A new Java file, SOSVM.java, contains the code for the following new functions as well as some important new system constants.

The new memory model uses a single array of integers to simulate physical memory. The memory is word-addressed and can be written using WriteMem(). The following example writes the value of -1 to physical memory cell 0 (word 0):

SIM.sosData.vm.WriteMem(0, -1)

The ReadMem() function will return the integer value stored at the address specified in the call:

j = SIM.sosData.vm.ReadMem(0)

The code in AppTests.java demonstrates the creation of two processes and the reading/writing of memory. It also demonstrates that the creation of separate paged address spaces for different JavaSOS processes remains to be done, since the setting of a value within one process should not affect the value of another process. In other words, the addresses used in the two calls need to be virtual addresses assigned separately to each process.

What to do

You are to modify the behavior of the code in SOSVM.java to support paged virtual memory. In particular, whenever a process attempts to Read or Write virtual memory it should access physical frames of memory that have been dynamically allocated to the process using demand paging. Initially each process will start out with an empty page table. The maximum size of physical memory is fixed at SOSVM.VMFrames (32) and the frame size is SOSVM.pageSize (64 words). This is also the page size and the disk block size. A process should be able to access all of the frames of physical memory using ReadMem() and WriteMem(). A reference to a page that has not been assigned to a page table entry for a process should cause a page fault. This will require you to add a fifth type of interrupt, along the same lines as the existing interrupt handlers (such as SIM.TimerIntVector). The page fault handler routine should allocate a new frame for the process (or page in a page from disk, if the page was removed from memory due to an early out-of-free frame condition) and resume the process that caused the page fault.

In addition to managing a per-process page table you should support paging to the disk drive. The entire disk surface, set to SOSDiskDriver.NumberOfDiskPages (512) will allow more than one process to fully address all SOSVM.VMFrames, with the "older" pages residing on the disk device. Once all the frames of memory have been allocated you are to use the second chance page replacement algorithm (see page 490 and 491 in the textbook). Make sure you use the entire set of frames when selecting a page to replace rather than just the frames assigned to the process that is in the midst of the page fault. The page replacement algorithm should be global, not local in scope.

The design of the page table entries is up to you. Make sure you look at what fields are required for the page replacement algorithm as well as for managing disk-resident pages. You will have to modify AppTests.java to create situations where paging will be forced to occur and the second chance algorithm is invoked.

Finally, modify SIM.java so that when the user selects "Exit Simulator" the following information is printed about the behavior of the virtual memory subsystem: