proj 2 -> proj 3

in project 3 you will be rewriting how virtual address spaces are
implemented and managed, and all of that will be new.  but you will be
using what you learned about virtual address spaces and COFF files
from project 2.  (and you will hopefully be able to reuse your global
page allocator from project 2 without modification.)

the bulk of the project is about getting demand page virtual memory
working, even with just one process (e.g., the swap4 and swap5 tests).
getting this working does not involve any system calls other than exit.

once it all works with one process, the next part is getting demand
paging working with multiple processes, i.e., working with exec.
since you'll be rewriting how process address spaces are supported,
you're going to actually be removing code that was in project 2 rather
than depending on it.  we will also not be testing join in project 3
(we tested it in project 2), but you can use join in your tests.

the file system call implementations (handleRead, handleWrite, etc.)
should not need to be changed since they use readVirtualMemory and
writeVirtualMemory.  the focus of this project is not on the file
system calls per se, but do note that if you want printf to work, for
example, it does rely upon rVM working.  you will reimplement rVM and
wVM in VMProcess to deal with the situation where a virtual page is
not mapped to a physical page.  if you had serious bugs with rVM and
wVM in UserProcess (e.g., printf does not work for you in project 2),
then meet with one of us.  note that we will not be testing corner
cases with any of these system calls since that is tested in project 2.

-   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

where and how to focus time in project 3

the focus for proj3 is on implementing demand paging and handling page
faults with memory intensive programs.  so my suggested sequence of
steps for implementing and testing are:

part 1 for a single process with the memory tests (swap4/5, matmult)
-- these are memory tests, they don't use any syscalls other than exit, and you can hold off implementing new versions of rVM/wVM for now

part 2 for a single process with the memory tests
-- now focus on implementing paging for the memory tests.
-- you can shrink physical memory using the "-m" flag to control how much paging the test programs will do.

part 1 for multiple processes with the memory tests
-- create test programs that exec the memory tests as children (or temporarily hardcode the child program name in handleExec)
-- but assign lots of physical memory so no swapping/paging is needed

part 2 for multiple processes with the memory tests

part 1 for a single process with rVM/wVM (write1, then write10)

part 2 for multiple processes with rVM/wVM (write1, then write10)

parts 3 and 4

NOTE: we will not be testing arguments to exec, any part of join, or
any of the corner cases for the I/O syscalls.  but you can use exec
with arguments and/or join in your tests if you have the functionality
implemented.

-   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

debugging strategies for paging (part 2)

debugging becomes more...interesting when you get to part 2 of project 3.
so the following only becomes relevant once you get to part 2.

if a test program stops working when you are implementing paging/swapping
in part 2 of project 3, here are some debugging strategies:

1) start with swap4/swap5; they do not use any syscalls other than
   exit (and in particular do not use tests that use rVM/wVM)

2) find the smallest size of physical memory where a program works.
   say it's P physical pages.  compare the sequence of page faults
   when running with P physical pages and when running with P-1 (a
   size where it doesn't work).

3) on every page fault, print out the page table of every process in
   the system and the inverted page table.  it is very verbose, but it
   will let you track how your code updates all of the tables on each
   page fault.  you can then look to see if the updates are what you
   expect.