Remove obsolete chapter.
parent
75c648a35a
commit
7fb3bae212
@ -1,55 +0,0 @@
|
||||
\chapter{Address space}
|
||||
|
||||
The system will have a single address space, as opposed to a separate
|
||||
address space for each process. We are targeting 64-bit
|
||||
architectures, which allows us to consider all disk memory as being
|
||||
part of the address space. Basically, main memory is a cache for the
|
||||
disk(s), and the virtual address of an object refers to its location
|
||||
on disk (with some exceptions as discussed below).
|
||||
|
||||
Half the address space (say the upper half) contains thread-local
|
||||
storage. Each thread has a local heap and a stack. For example, the
|
||||
thread-local address space can be 16 or 32MiB of which the local heap
|
||||
can be around 4MiB (smaller than the size of the cache). Thread-local
|
||||
storage must have associated physical disk memory.
|
||||
|
||||
The other half of the address space (say the lower half) contains
|
||||
mainly the global heap, aside from a small amount of space dedicated
|
||||
to interrupt handlers and other architecture-imposed data structures.
|
||||
The address space for the heap is divided in two halves. Only one
|
||||
half requires associated physical disk memory. Thus, aside from the
|
||||
architecture-imposed data structures, the two halves map to the same
|
||||
disk space. The reason for this organization is that it makes it easy
|
||||
to implement the global garbage collector
|
||||
\seechap{chap-garbage-collection}. The method invented by Kermany et
|
||||
al \cite{Kermany:2006:CCI:1133981.1134023} divides the heap address
|
||||
space in two halves, but requires physical memory only for a little
|
||||
more than half of it.
|
||||
|
||||
\refFig{fig-address-space} illustrates how the organization of the
|
||||
address space might look on a computed equipped with the x86-64
|
||||
processor. This processor has a theoretical virtual address space of
|
||||
$2^{64}$ bytes, but the real virtual address space might be limited
|
||||
to $2^{46}$ bytes. If so, then the middle of the theoretical address
|
||||
space is not part of the real address space.
|
||||
|
||||
\begin{figure}
|
||||
\begin{center}
|
||||
\inputfig{fig-address-space.pdf_t}
|
||||
\end{center}
|
||||
\caption{\label{fig-address-space}
|
||||
Address space on x86-64.}
|
||||
\end{figure}
|
||||
|
||||
As \refFig{fig-address-space} illustrates, the available disk space is
|
||||
typically a small fraction of the possible virtual address space. For
|
||||
example, $2^{46}$ bytes is $64$ terabytes which is two orders of
|
||||
magnitude larger than a typical hard disk. In that case, the disk
|
||||
space is divided (not necessarily in equal parts) between the global
|
||||
heap and thread-local storage. Furthermore, the size of each
|
||||
thread-local storage can be configured according to whether a large
|
||||
number of threads should be possible, or, on the contrary, each thread
|
||||
should have a large stack.
|
||||
|
||||
Main memory is not shown in \refFig{fig-address-space}, simply because
|
||||
it just works as a demand-paged cache for the available disk space.
|
Loading…
Reference in New Issue