Memory Management

1
Memory Management

• Key issues
• Allocating the main memory (RAM) for use by
  different processes
• Mapping addresses used in a process to addresses
  in physical memory
• Protecting memory owned by one process from being
  accessed by another
• Making good use of the different memory systems
  of the computer
• Many programs are usually in memory at the same
  time, but where? The physical memory addresses
  an image is loaded into by the OS vary each time,
  and are not known when it is created by the
  compiler and linker.
• With different programs in memory, need to be
  able to prevent them interfering with each other,
  while also allowing sharing if appropriate
• As processes start and finish, the available free
  memory becomes fragmented. It may be impossible
  to start a process because enough contiguous
  memory is not available, even though overall
  there is enough.
• Ideally, each process should be able to use the
  full address space of the machine. In practice
  only a small fraction of this amount of RAM will
  be available to a process, but maybe we can use
  the disc to pretend.
• Many different types of memory, from registers to
  caches to RAM to discs. Access times and
  capacities vary by a factor of about ten million.

2
Virtual addressing 1

• N.B. not the same as Virtual memory see later
• The logical or virtual memory addresses used
  by a process are mapped to the actual
  physical addresses in RAM.
• Usually done by mapping e.g. 4 kilobyte pages
  of logical addresses to 4 kilobyte page frames
  of physical RAM.
• e.g. assuming a 32 bit address space, use the low
  order 12 bits to address bytes both within the
  page and within the page frame, but replace the
  high order 20 bits with a different 20 bits for
  the physical page frame.
• The mapping from logical page number to physical
  page frame could be done using a page table,
  where the index into the table is the logical
  page number, and each entry is a physical page
  number. Each process would have its own page
  table set up by the operating system, containg
  references to the physical memory allocated to
  the process by the OS.
• In practice, one table would be too big and
  mostly empty, so two or more tables are used -
  e.g. a page directory table indexed into by the
  top bits of the virtual address, giving the
  physical page frame where a page table starts,
  which is indexed into by the next bits of the
  virtual address, to give the physical page frame
  address. Merits and Demerits ?
• The start address of the page directory table for
  a process is usually placed in a special
  register, and stored in the PCB for the process.

3
Virtual Addressing 2

• The page table based approach has many advantages
• Memory used by a process can appear contiguous to
  it, even though the physical page page frames are
  all over the place. Only fragmentation is pages
  being partly empty (internal fragmentation),
  not a big problem.
• The same page frame in RAM can be mapped into the
  address space of many different processes this
  is particularly useful for read-only pages.
• Since OS kernel functions are used by all
  processes, why not assign certain virtual
  addresses to them, (e.g. from 0xc0000000
  upwards), and have one page table used by all
  processes for those virtual addresses.
• The page table entry can be extended to contain
  other information, for example the access rights
  of the process for that page, whether it has been
  changed, whether it can be accessed in user
  mode, how long since it was last used, how often
  it has been used.
• A process can only see the physical page frames
  referenced in its page tables the others dont
  exist for it. Need to ensure that a process
  cannot change its own page tables, and handle
  references to empty entries
• The scheme can be extended naturally to support
  virtual memory, where the physical page is not
  in RAM at all, but is out on a disc see later.
• However, it effectively requires additional
  hardware support the TLB

4
Virtual Addressing 3

• The model presented so far suggests that each
  memory access involves accessing the page
  directory table to get the start of the page
  table accessing the page table to get the
  actual page frame accessing the page
  frame to get the data
• Rather a lot of work for one memory access!
• In practice, access to computer memory usually
  displays locality of reference the next byte
  accessed is likely to be in the same page frame
  as a recently accessed byte. So if the physical
  page frame corresponding to a virtual page is
  remembered, all the looking up of tables can be
  short circuited when another reference to a byte
  in that page occurs.
• Most systems provide a translation lookaside
  buffer (TLB) containing (virtual page address,
  physical page frame address) pairs, and
  implemented as an associative memory all the
  virtual page addresses can be compared with a
  given virtual page in one go, and the
  corresponding physical page frame address
  returned. This can usually be done in parallel
  with some other part of the operation of the CPU,
  so that the mapping from virtual to physical adds
  no extra delay at all.
• Of course, if the no entry exists in the TLB for
  a particular virtual page, the looking up
  rigmarole above has to happen the TLB is then
  updated, maybe overwriting the least recently
  used entry.

5
Virtual Memory 1

• Its easy to see how to extend the page table
  idea so that the physical data is on disc rather
  than in RAM.
• Since disc is maybe ten million times slower than
  RAM, this seems little use at first sight.
• However, most programs display locality of
  reference in space and in time a large program
  may spend nearly all its time in just a few small
  parts of the code. If this is the case, only
  these active parts of the program need to be in
  precious RAM. The rest can be left on disc, and
  pages be brought into memory from disc when
  required demand paging. As this should seldom
  happen, the overhead is tolerable - of course, if
  the program does not display locality of
  reference performance will be disastrous.
• The memory needed by a process for its current
  operations, its working set, needs to be
  allocated to it as RAM, otherwise the system will
  spend most of its time on disc accesses, and
  little processing will be done thrashing
• However, if an adequate RAM allocation is made,
  even though much less than that required to hold
  the whole program, it can seem as if the whole
  program is in RAM - virtual memory
• This is particularly useful when many processes
  are in memory at once they can all be kept
  happy without any of them being fully in RAM

6
Virtual Memory 2

• So when an instruction accesses memory things go
  something like this
• Try the TLB with the virtual page
• if in TLB, put page frame no. in address,
  access RAM, done.
• if not a TLB hit, OS uses the page tables
• if the page not in RAM, page fault
• OS decides which page in RAM to replace
• if page was changed writes it to disk first in
  pagefile
• update page table to indicate this page now on
  disc
• gets required page from disc into RAM
• update page table entry for virtual address
• update TLB
• restart instruction it retries TLB, but
  now there is a hit
• This works as long as each process has enough RAM
  to hold its working set
• One significant issue is the replacement policy
  used when the TLB or the RAM are full many
  different approaches

7
Virtual Memory 3

• Making all this work efficiently is a source of
  considerable complexity in operating systems.
• The OS typically maintains a table of free pages
  and a table of modified pages, with the later
  only written back to disc and freed when free
  pages run low. Modified pages should be zeroised
  before being freed for good security.
• To store pages that have been modified, the OS
  will typically use a pagefile (sometimes
  misleadingly called a swapfile). Pages that were
  not modified can simply be reloaded again from
  disc.
• The OS must also set up and maintain the page
  directories and page tables for each of the
  processes and swap these when switching processes
  as threads in a process use the same memory,
  switching threads not so bad
• In addition, the OS may totally swap out some
  process from memory to make RAM space available,
  making the corresponding changes to all the
  tables (an old fashioned approach).
• And all of this can be upset if programs are
  written so that they do not display locality of
  reference. Its worth noting too that if a
  process uses up the free pages or modified pages
  rapidly, it can affect performance of other
  processes, not just itself. System can end up
  thrashing

8
Locality of Reference

• The next physical address accessed by a program
  tends to be near other addresses it has used
  (locality of space) and near an address it used
  recently (locality in time).
• Usually the virtual addresses used in a program
  will fall into various segments e.g. for the
  code, for the run time libraries, for the data,
  for the stack and within each segment there
  should be good locality of reference if things
  are written correctly.
• On modern processors there are a number of fast
  memory caches between the CPU registers and RAM,
  since RAM access speeds are now much slower than
  CPU speeds.
• Things get progressively worse as we move from
  working mostly from the registers, from the
  fastest cache, from the slower cache, from RAM,
  from disc, from CD.
• Its easy to write code with very loose loops, or
  many long calls, or with data improperly handled
  (multidimensional arrays are great for this). The
  effects on performance can be startling
• Try running the simple Java program that follows
  (the funny symbol in the println is ctrl-G, which
  causes a bell sound). What does it tell you about
  the way Java stores 2-D arrays?

9
Lack of Locality in Java

• class Mylocality
• / Not RAM vs Disc but Cache vs. RAM is the main
  issue here /
• public static void main(String args)
• int a new int81921024
• //int a new int10248192
• System.out.println("Starting row order") /
  
• for(int i0i
• for(int j0j 1
• System.out.println("Done row order/nStarting
  Column Order ")
• for(int j0j
• for(int i0i
• System.out.println("Done column order ")