Main Parts: Due November 3rd

• 3. (12 points) Implement a simulation of a memory management system. For this part, your system should have the following features:
  • The system must use the Simple Paging scheme (as described in Stallings in Section 7.3, page 304). This scheme means that you need things such as page tables, etc.
  • Pagesize = 128 bytes. Number of page frames (memorysize) = 80.
  • Simulate processes (the entities for which memory is allocated) by having the main program generate (on the fly, as needed) a list of process creation requests. Each of these requests should contain two random values: the size (from 1 byte, to 25 times the pagesize) of the process, and the lifetime of the process (from 2 to 30 units).
  • The main program should loop (70 times):
    • Display a current snapshot of memory. (For each page, show the PID of the process that owns it. A table would be good.)
    • Select the size and lifetime for the process, as specified above. Display these values.
    • Allocate memory for the process (or print failure message if insufficient memory available for that process).
    • Display number of free pages remaining.
    • Decrement lifetimes of all existing processes.
    • For each process now with lifetime 0, display the process's Page Table, free up the memory allocated to it, and display number of free pages.
  • After the loop, the main program should continue decrementing the lifetimes of any remaining processes, until they all eventually reach 0, and are freed. And it should then print out summary numbers, indicating: the number and percentage of requests that failed.
  • All this should occur in a single process, with no additional threads.

• 4. (15 points) Implement a simulation of a memory management system. For this part, your system should have the following features:
  • The system must use the Simple Paging scheme (as described in Stallings in Section 7.3, page 304). This scheme means that you need things such as page tables, etc.
  • Pagesize = 128 bytes. Number of page frames (memorysize) = 80.
  • Simulate processes (the entities for which memory is allocated) by having the main program generate a random size for the process (from 1 byte, to 25 times the pagesize, same as previous part), allocate memory for it (same as previous part) but then create a new thread for each process.
  • Each of these threads should choose a random value to act as its lifetime. However, this should be a number of milliseconds, between 0 and 200.
  • The main program should loop (70 times):
    • Display a current snapshot of memory. (For each page, show the PID of the process that owns it. A table would be good.)
    • nanosleep for 10ms.
    • Select the size for the process as described above. Display this value.
    • Allocate memory for the process (or print failure message if insufficient memory available for that process).
    • Display number of free pages remaining.
    • Create a new pthread for this process.
  • After the loop, the main program should wait for any remaining threads to complete. And it should then print out summary numbers, indicating: the number and percentage of requests that failed.
  • Each thread should:
    • nanosleep for the randomly chosen number of milliseconds (between 0ms and 200ms, which is between 0 and 200,000,000 nanoseconds).
    • Display a message indicating how many milliseconds it slept.
    • Display a message that it is about to quit.
    • Display the process's Page Table.
    • Free up the memory allocated to it, and display number of free pages.
    • Quit.

• 5. (23 points) Implement a simulation of a memory management system. For this part, your system should have the following features:
  • The system must use the Simple Paging scheme (as described in Stallings in Section 7.3, page 304). This scheme means that you need things such as page tables, etc.
  • Pagesize = 128 bytes. Number of page frames (memorysize) = 120.
  • Simulate processes (the entities for which memory is allocated) by having the main program generate a random size for the process (from 1 byte, to 50 times the pagesize), allocate memory for it (same as previous part) but then create a new thread for each process (same as previous part, except that what the threads do is different).
  • Each of these threads will actually run a simulated program, as described below. So their lifetimes will be determined by how long their ``program'' takes to run.
  • The main program should loop (70 times):
    • Display a current snapshot of memory. (For each page, show the PID of the process that owns it. A table would be good.)
    • Select the size for the process, as described above. Display this value.
    • Allocate memory for the process (or print failure message if insufficient memory available for that process).
    • Display number of free pages remaining.
    • Create a new pthread for this process.
  • After the loop, the main program should wait for any remaining threads to complete. And it should then print out summary numbers, indicating: the number and percentage of requests that failed.
  • Each thread should:
    • Perform between 8 and 100 simulated ``blocks'' of code. (See below.)
    • Display a message that it is about to quit.
    • Display the process's Page Table.
    • Free up the memory allocated to it, and display number of free pages.
    • Quit.
  • Remember that you need to do locking on shared data structures, or else they will be corrupted.
  • Each ``block'' is one of the following. Each one operates starting at the current position. Before the first block runs, current position is address 0 in the simulated process's address space. size is number of bytes in this process, as chosen by the main program. (See ``Hints and Implementation Details'' section for explanation of what the percentages in the following list mean, in case they're unclear.)
    • 60% of the time, linearly access n memory locations (0 <= n <= (size/2)).
    • 20% of the time, loop m times linearly accessing n memory locations (0 <= n <= (size/8)) (2 <= m <= 6).
    • 20% of the time, jump to n locations away from current location (-(size/16) <= n <= (size/16)).

    Before performing the action for each block (linear access, loop or jump), it should print out a one-line message, containing PID, action-type, and action parameters.

    Treat all math on memory addresses as being modulo the size of the process space. For example, within each block's run, if a linear or loop would overflow the end of memory, have it continue back at the front, as if memory was a circular list. (For example, if current position is 80, and size is 100, and the value of n randomly chosen for a linear access is 35; then the addresses accessed should be 80,81,...,98,99,0,1,...,13,14.)

• 6. (25 points) Implement a simulation of a memory management system. For this part, your system should have the following features:
  • The system must use the Virtual Memory Paging scheme (as described in Stallings starting on page 324). This scheme means that you need things such as page tables, a free lists, etc.
  • Pagesize = 128 bytes. Number of page frames (memorysize) = 120.
    Number of pages of swap space = 400.
  • Simulate processes (the entities for which memory is allocated) by having the main program generate a random size for the process (from 1 byte, to 50 times the pagesize, same as the previous part), allocate memory for it (same as previous part) but then create a new thread for each process (same as previous part).
  • Each of these threads will actually run a simulated program, as described below. So their lifetimes will be determined by how long their ``program'' takes to run.
  • The main program should loop (70 times):
    • Display a current snapshot of memory. (For each page, show the PID of the process that owns it. A table would be good.)
    • Display a current snapshot of swap space. (For each page, show the PID of the process that owns it. A table would be good.)
    • Select size for the process. Display this value.
    • Allocate swap space for the process (or print failure message if insufficient memory available for that process).
    • Display number of free pages remaining, in each of memory and swap.
    • Create a new pthread for this process.
  • After the loop, the main program should wait for any remaining threads to complete. And it should then print out summary numbers, indicating: the number and percentage of requests that failed, the number of Pagein's required, the number of Pageout's required, the number of Dirty/Modified pages written back to disk.
  • Each thread should:
    • Perform between 8 and 100 simulated ``blocks'' of code. (See below.)
    • Display a message that it is about to quit.
    • Display the process's Page Table.
    • Free up the memory allocated to it, and display number of free pages in each of memory and swap. (Note that you need not call Pageout on the pages of a process that is about to quit!)
    • Quit.
  • Each ``block'' should operate exactly as in the previous part, except that 20% of the time, the block should additionally be considered a ``write block'', and calls to the access function should also set the Dirty/Modified bit.
  • For each ``access'' to memory, call a function Access (with the processes virtual address) and have it do the following:
    • Use page table to map to real address.
    • If that real page is not currently in memory, then call Pagein for that page.
    • Set the Used bit for that page.
    • If the block is a ``write block'', then set the Dirty/Modified bit too.

  • The Pagein function implements the page replacement policy, as follows:
    • If there are no free pages in main memory, then use the Clock algorithm (Stallings page 345, 346) to find a page to replace, and call Pageout on that page.
    • If there were free pages, claim one.
    • Load the page (on which Pagein was called) into memory.
    • Update tables accordingly.
    • Print out a line of output indicating what was/had-to-be done.
    • Display a current snapshot of memory.
  • The Pageout function does all the work required to free up a page in memory:
    • Finds the process to which this page belongs.
    • Finds the swap page associated with it.
    • If its Dirty/Modified bit is set, writes it out to that swap page.
    • Updates various tables, as needed.
    • Print out a line of output indicating what was/had-to-be done.