CS 439: Project 4

Translation Look-Aside Buffer and lazy allocation of Page Table Structures

Due Monday, 12/3/12, 11:59PM
No project, regardless of the number of available "slip days", may be turned after Friday, 12/7/12, 11:59PM

Individual or Team of Two

In this project you will add TBL support and lazily-constructed multi-level page tables to project3.
Your job is to modify your Project3 solution to support in two phases:

- Lazily Constructed Multi-Level Page Tables (Phase I)

- Translation Look-aside Buffer (Phase II)

What you get

You are provided with: project4_cs439.zip
wget http://cs.utexas.edu/~rockhold/CS439/project4/project4_cs439.zip
This is in Eclipse-importable format.

What you need to do

This project is designed to be completed in two phases. Finish phase I before starting on phase II.

In phase I, the simulator uses only PTEs (just like project3), but this time your PTEs must be lazily allocated.

Phase II runs the simulator using TLBs (and still PTEs, of course). As in phase I, your PTEs must be lazily allocated.

Common setup for phases I and II

This project uses the same simulator package from project 3.
So, setting up Eclipse Run/Debug Configurations are the same as project 3.
Likewise, the provided Makefile has the same targets as before, e.g. classes, clean, along with targets to run and diff tests for both phases.
The same -v and -vv flags are used by the simulator to control the level of verbosity.
As in project 3, there are 6 different configuration files named config_N, where N is (1,2,3,4,5, or 6). These are common to each phase.
The same configuration values that were in project3 are in project4.

Phase I

Phase I - Requirements

  1. All slots in the Level 1 PageTable must be null, unless pages have been allocated in the range for that slot.
    If not null, a slot entry will be a reference to a Level 2 PageTable.
  2. All slots in the Level 2 PageTable must be null, unless a page has been allocated for that slot. If not null, that slot entry will point to a valid PageTableEntry.
  3. As in project2:

Phase I - Testing

In phase I, you will run the simulator in PTE "mode".
This is accomplished by NOT specifying the -t flag. (the "t" in -t stands for TLB).
So, to run config_1 in phase I to generate output to compare against what's expected:

         $ make config1_pt

or

         $ make classes
         $ java -cp bin simulator.Simulator -v config_1

You can use the Makefile to run all the tests for phase I with:

         $ make configs_pt

You can set it as a Run or Debug configuration in Eclipse with project:project4_cs439, Main class:simulator.Simulator, Program Arguments: -v config_1
Note that you can produce the "very verbose" output by specifying -vv instead of -v
The very-verbose reference output is located in the outputs_pt directory with file names that include vv.

Phase II

Phase II - Requirements

  1. Implement the TLB and TLBEntry classes in CPU.
  2. When translating an VA to a PA, the CPU will first search the TLB. If a hit is found, it will use the frame in the TLBEntry to form the PA.
    Otherwise the CPU will use the (lazily-constructed) PTE to perform the xlation.
  3. The use of true LRU for the replacement policy of the TLB entries. TLB Entries are *not* tagged with a PID, so the CPU’s TLB must be invalidated on every context switch (except when dispatching the same process whose quantum expired – see ICPU.getLastDispatchedProcess()), and whenever mappings are removed from the currently running process.
  4. The frame replacement policy is true LRU. So your TLB management code must keep order the references to TLB entries, and the OS must use this ordering when making frame replacement decisions. As needed, the OS will "read" these time-stamps and use them to update its frame LRU time-stamps (the CPU should NOT call IOS.setFrameReferencedTime() on PTE "hits" as it does in phase I.) See ICPU.getTLBEntries().
  5. The count (not log2 of the count) of the number of TLB Entries in the TLB is accessed by SystemInfo.getTLBEntryCount() and is guaranteed to be a power of 2.

Phase II - Testing

In phase II, you will run the simulator in TLB "mode".
This is accomplished by specifying the -t flag. (the "t" in -t stands for TLB).
So, to run config_1 to generate output to compare against what's expected:

         $ make config1_tlb

or

         $ make classes
         $ java -cp bin simulator.Simulator -v -t config_1

You can use the Makefile to run all the tests for phase I with:

         $ make configs_tlb

You can set it as a Run or Debug configuration in Eclipse with project:project4_cs439, Main class:simulator.Simulator, Program Arguments: -v -t config_1
Note that you can produce the "very verbose" output by specifying -vv instead of -v
The very-verbose reference output is located in the outputs_tlb directory with file names that include vv.


Some debugging help

The Simulator supports 3 levels of logging, implemented in the base.Debug class:

  1. Debug.log(String message) will always output the specified message.
  2. Debug.info(String message) will produce output if Simulator is run with either the -v flag, or the -vv flag.
  3. Debug.user(String message) will produce output only if the Simulator is run with the -vv flag.

The reference solution for OS and CPU is sprinkled with a few uses of Debug.user() messages.
For your reference, I've included output files in the outputs_pt directory that were produced running the reference solution with the -vv flag.
These files are named config_?_vv.txt (note the double v's).
So, if you get stuck, you can look these over to get a sense of what the reference solution is doing.
If you want, you can sprinkle your code with calls to Debug.user("...") at what should be the same places where they likely appear in the reference solution.
Likewise, you can sprinkle calls to Debug.user() throughout your code, knowing full well that they won't interfere with getting the correct output when you test you code (we only test your solution with -v, not -vv.)

Files to turn in

  1. CPU.java (Your completed implementation)
  2. OS.java (Your completed implementation)
  3. README (sekelton provided, but you need to complete it)

You need to fill out the README file.
When you're finished with the project, use the make target:

           make turnin

which will create a tar.gz file of your work and invoke turnin for you.
If you'd like to create the tar.gz file and look it over, you can create it without doing the turnin using:

             make turnin_setup