Text preview for : Alto_Mesa_1974.pdf part of xerox Alto Mesa 1974 xerox mesa Alto_Mesa_1974.pdf
Back to : Alto_Mesa_1974.pdf | Home
Inter-Office (VJem.ornndum
To CSL, SSL Date
June 12,1274.
From Jim Mitchell Location PARC-CSL
Subject What Mesa needs in an Alto Organizlltion
Virtual Memory Scheme
Since there has been much discussion of Virtual Memory (VM) schemes
in the context of Alto "Gold Coins", it seemed appropriate that the
desires of the Mesa group be specified. This memo is a reasonably high
level description of the characteristics which would be helpful to Mesa
in a VM scheme.
Mesa Object Files
A Mesa Object Module (file) is composed of two main parts, each of
which is a contiguous group of pages in the file:
header info
n pages
object code
literals
symbol pages
tables
Generally, s is larger than n, and sometimes s is twice as large as n.
The action of "loading" a Mesa module requires only that the code
pages be mapped into memory. The code is never altered in any way - all
external connections (generally procedures and ports) are in the data
associated with a program. A Mesa routine (procedure or coroutine) is
uniquely identified by a frame containing its state and local variables,
and many routines may share the code in an object module. The information
which allows Mesa to associate a symbol table and code with a routine is
kept in a frame called a creator frame. The act of "declaring" an object
'file to Mesa causes a creator frame for that file to be made. Instances
of that module can then be created simply by transferring control to its
creator; the result is a new routine. The cost of creating new instances
is roughly comparable with the cost of a procedure call.
The header information in the code block of an object file contains
sufficient information to enable the Mesa loader to manufacture a creator
for it.
Abstractions for Managing (Overlaying) Code Blocks
A contiguous set of file pages is called a ~ group in Mesa, and
is identified by three values:
filehandle: some handle on a file by which the pages of the file
can be named (for example, a JFN in Tenex);
pagebase: the page in the file which corresponds to page zero in
the page group;
size: the numb~r of pages in the group.'
A page group is accessed by a PG-handle (actually a protected [sealed]
pointer) and page groups may be created, destroyed, and swapped into
memory or out. More than one page group may, in principle, be associated
with the same pages in a file. On Tenex this is accomplished by PMAPping
the appropiate file pages into the Tenex VM. One special kind of page
group, called a Window group, is provided: the pagebase and size attri-
butes of such a group are alterable after it is initially set up, and it
can thus "window" pages of the file to which it is attached.
The code and symbol table parts of a Mesa module are each modelled as
a fixed page group by the Mesa loader, overlaying and debugging software.
The main implication of this is that Mesa code is "svJapped" (overlayed) in
units corresponding to the code in a single module. Symbol tables, being
separately swappable, only consume VM space when needed by debugging or
dynamic (LISP-like) binding mechanisms.
The following diagram portrays the relationships between the Tenex
page-grouped VM as seen by Mesa, File memory, and Maxc disk storage (see
next page, please):
-2-
D:~k
sCI.) I'v..~-L
. One obvious conclusion from this diagram is that the logical grouping
of fi1e pages which Mesa considers useful is not at all maintained at the
level of disk storage. A second observation is that the Tenex-provided VM
is being treated as a real memory into which a much larger VM, composed
of page groups, is mapped. For obvi ous effi ci ency reasons_ on Tenex, only
Mesa code and symbol tables are considered swappable because pointers to
them can be controlled by software (for not-in-memory traps, etc.).
Mesa/Alto
We would like to propose a VM scheme for Altos which supports a struc-
ture such as the following:
A