Back to Operating Systems Home Page

Notes on VM

> Hello mr prof:

Hello mr stdnt: 
 
> 1) Do all process have the same virtual address space in terms of each
> individual process? For example: If process A have, say (hyperthetically),
> virtual address 1 to 10, then, do process B also use vitual address 1 to
> 10 also? 

(I suppose you mean "hypothetically".  A hyperthesis is (maybe) a big PhD's 
work. ;-)

All processes "see" the same virtual address space, in the sense that
they all use addresses from 0 to 2^s, where s is the size of an address
in the given architecture. For example, from 0x0 to 0xffffffff in a 32 bit 
architecture, i.e. 4 GB of space. 

However, in the case of an operating system running in the context of the
current process (e.g. UNIX), it is often the case that the higher regions
of this address space are reserved for the data and stack that the kernel
uses when it runs on behalf of a process. So the virtual address space
that a program can access directly is smaller: if the highest bit is
used to differentiate between user-mode segment and kernel-mode segment,
than the user-mode address space is cut to 2GB. Which is still a lot,
isn't it?

> If so, is it the operating system's job to make sure that each
> process's page table points to different frames of memory? 

Right. Or to make sure that, if they point to the same frame, that 
frame is either 
        [A]  marked "copy-on-write" in the page tables of both
        processes (so they get independent frames as soon as they try to
        change the page's content), or 
        [B] is really a piece of memory which the processes explicitly
        asked to have in common. 

For example, case [A] happens in UNIX when a process forks; case [B] when
a shared memory segment is attached by two processes. 

An interesting case of copy-on-write, mentioned today at the end of
the class and in the tutorial, is the so-called "anonymous mapping". A bit
in the page table entry can be used to indicate that a page has been
committed to the process's address space, but no frame has been allocated
for it yet. So the process can legally reference addresses in that page,
but a frame is actually allotted to the process only on the first write, and
at that point the page mapping from anonymous turns into a "named" one, i.e.
named with the frame mapped for the page. Garbage or a bunch of zeros is 
returned instead if the process tries to read from it before writing.

This technique  prevents the kernel from overcommitting "in 
one shot" an amount of memory that might instead be needed only a chunk
at a time. The example I made in the tutorial:

                malloc(1 << 24); /* allocate 4096*4096 bytes */

is a case in point - normally a process won't write immediately
to all that memory: it might need to do I/O for filling it, so other
processes could use that memory in the meantime.

> If so, then how
> do the problem of a process writing to another process's memory space
> araises? (since it has no way of knowing or accessing other process's
> memory). 

It doesn't. But a process may still generate invalid virtual addresses
(and thus cause a segmentation fault or bus error trapped by the CPU). 

It may try to do a write access to a page marked READONLY (e.g. a page
containing program instructions). Or it may try to reference a page which
is not in the page table (e.g. a page between the bottom of the stack and
the top of heap). Or it may try to access a page belonging to the
kernel-mode segment without going through a system call. All the above
attempts will be trapped as "segmentation faults" or "segmentation
violations" by the MMU/CPU, and in response a trap handler in the OS will
"inform" the process of the error (e.g. sending SIGSEGV in UNIX). 

Or the process may generate an address which, even if it's inside the
process's address space, makes no sense for the given architecture. E.g.
an odd address in an architecture like the M68000, which can access memory
only 2 bytes at a time (try dereferencing an odd pointer in C on that).
In this case the MMU/CPU traps a "bus error", because it can't even
put the address on the bus. 

> 2) also on the same topic, remember how you said the CPU have the base
> register to use to compute the memory boundary check for each process, I
> just don't know how this is necessary since all the process are using
> virtual memory, and each virtual memory address space is already mapped by
> the OS on the page table, so this means the process will always be using
> its own addressing space, isn't it ?????

Good question.

The "bound an base" registers which I described in the first few lectures
provide a basic mechanism for separating the physical memory into
independent chunks for each process. Basic enough that (a) you can
understand how several process images can co-exist in memory without
interfering with each other even at the beginning of an OS course, and (b)
it can actually be used to implement multitasking in (old) systems not
using virtual memory. 
 
With virtual memory thinks become more sophisticated. The "base register" 
now becomes the register that the MMU uses to store the base address of
the page table for the current process (or page directory, if a multilevel
paging scheme is used). If segmentation is used in addition to paging,
then there are base registers for each process segment (text, data, heap,
stack, kernel-mode data, kernel-mode stack), each pointing to a separate
page table (or page directory). The "bound register" now contains the
index of the last page allocated (and there are as many as segments, if
segmentation is used). 


> I am really CONFUSE on this issue, and I would really like to clear this
> up........ =)

Hope the above sheds some light. More on this in the next lecture and
tutorial.

> ps. Can you give us an EASY final exam (heehee... just a joke  ;-) )  

My finals are always easy - if you come prepared  ;-)

Ciao
Franco

P.S. Now that you know how big the size of a virtual address space for a
process can get, you should be able to answer by yourself that infamous
old question: 

        "Can the heap and that stack bang on each other, if I malloc
         too much and/or nest too many subroutines?"