Pilot: An Operating System for a Personal Computer (1980, Xerox) Optimistic 
Incremental Specialization: Streamlining a Commercial Operating System 
(1995, Oregon) Jonathan Ledlie February 2, 2000 The main idea behind the Pilot 
project appears to be to take lots of other people’s good ideas for larger machines 
and try them on a personal computer.  The problem is they miss one of the most basic 
ideas, which is to keep the OS itself flexible -- and tying your OS to one language, 
namely Mesa, goes against that completely: Since other languages are not 
supported, many of the language-independence arguments that tend to maintain 
distance between an operating system and a programming language are not relevant.  
In a sense, all of Pilot can be thought of as a very powerful runtime support package 
for the Mesa language. This is absurd; the arguments remain relevant because 
computers must be able to thrive in heterogeneous systems, one where programs 
written for one system can run on another and where few assumptions can be made about 
the machine you are talking with at the other end of the wire.  Still, Pilot clearly 
does have many good ideas, particularly in the realm of personal computers.  On a 
personal computer, processes should not fight each other for resources -- they 
should cooperate and be honest about their needs, unlike on a shared system, where 
giving another user more memory almost always means that you have less.  Their idea 
for virtual memory Spaces, where each process specifies its working set, works on 
a single-user system, because a user would want resources to be best spread among 
all of her current processes. Mainly taken from UNIX, a good borrowed concept was 
their use of TCP, streams, and filters.  Three ideas bothered our group.  First was 
the relaxation of security, because the machine, even though a single-user 
system, remains vulnerable because it is presumed to be on a network.  Second, all 
processes share the same address space – this seems to be begging for trouble.  
Third, a regular user probably would not want the CoPilot debugger to 
unconditionally start on an application fault. Our group found little to fault 
with the Optimistic paper -- maybe we need twenty years’ hindsight like for the 
first paper.  We felt that it had two main achievements.   It was a proof of concept: you 
can take an already optimized segment of an operating system and tune it so that the 
common cases go even faster.  Secondly, in proving their concept, they attempted to 
formalize the currently ad hoc bottleneck widening process: “Hence, the goal of 
our experiments is to gain an understanding of the specialization concept rather 
than simplely to optimize the component in question.”  Instead of deciding which of 
the sub-system calls to use once, their idea is to “apply the run-time partial 
evaluator again at every point where new invariants become known.”  Accounting for 
these invariant with each system call (read in this case) is what they have pruned 
from the calls.  For example, read does not need to check the block size with every 
call; it should do this once with open().  They call their idea optimistic because 
these invariants and quasi-invariants, which change more often, are both hoped to 
change very infrequently.  If they change often, their idea becomes not so good.  The 
difficultly, then, becomes knowing what these invariants are and knowing where in 
the system you need to check for them, which requires an “expert knowledge of the 
system implementation.” 

Pilot: An Operating System for a Personal Computer
David Redell, et al. (Xerox)

Pilot is an operating system designed and built by researchers at
Xerox in the late 1970s in response to the continued decrease in the
cost of digital computers.  It was then possible to consider building
personal computers attached to high-speed LANs and slower WANs as
opposed to timesharing in a large, central computing facility.  As a
result, it was possible to consider building a system that emphasized
the interaction between user and computer.  For instance, the personal
computer that ran Pilot had a mouse, keyboard, and graphics display,
not just a teletype.  Other examples of the shift in emphasis between
timesharing systems and personal computer operating systems such as
Pilot include so-called "defensive" protection mechanisms rather than
"absolute" ones.  In the PC environment, the authors argue, errors
rather than malicious attacks are the more significant problem.  As a
result, Pilot relies on the strong type-checking of the Mesa language
rather than on stronger hardware-based mechanisms.  In a similar vein,
Pilot also makes extensive use of hints from user programs about which
pages to evict, which pages to map, etc.  In a timesharing system,
this approach can lead to problems of isolation and protection,
whereas in a PC environment, it allows for optimizations that lead to
better performance and responsiveness.

The highlights of the system include flat files stored on mountable
volumes (which may be on physically removable media), virtual memory
swapped in whole units known as "Spaces" organized in to a tree
structure, stream I/O interfaces that permit dynamic construction of
pipelines, shared memory for tightly coupled IPC, and a
"Communications" facility that permits remote network access and
internetwork routing.  The design of the system as a whole is tightly
coupled with the implementation language, Mesa.  Mesa is itself
interesting as a systems programming language since it provides stong
typing, procedure calls, coroutines, concurrent processes, and signals
(exceptions).  As a result, the Mesa runtime is non-trivial and is
tightly integrated with the Pilot implementation.