Writeup Notes of ``StarOS Multiprocess OS''
===========================================

The first thing that struck me about this paper is that it outlines a system
very much like the modern day Message Passing Interface (MPI) commonly used in
Beowulf clusters. The difference is that the StarOS system as a whole is at a
lower level: it's an OS, not a library. It is also designed for specialized
hardware, rather than a heterogeneous mix of compute nodes and high-level
interconnects (e.g. x86 and Ethernet or Itanium and Infiniband). This is
understandable because StarOS was written in the late 1970's.

The hardware underlying the StarOS system looks to me like the kind of SMP
hardware that can be found today making up Beowulf cluster computer nodes.
There are one or more cores addressing a bank of memory at equal speeds, with
interconnects between ``nodes''. Each compute core is attached to a switch that
accesses either local memory or remote memory. The switch is on a bus
controlled by hardware dedicated to managing memory requests and data transfers
between nodes. The memory buses of each ``cluster'' of nodes can be connected
to another cluster, forming the complete Cm* machine -- the hardware that
StarOS runs on. Therefore the memory hierarchy of the system is NUMA as remote
memory will not be as fast to access as local memory.

The primary purpose of StarOS is to support ``task forces'': a group of
processes working on a single problem or computation, all with shared
resources. They appear to be ideal for scientific or engineering computing,
where a single task can be parallelized, but perhaps less so for desktop
computing. Desktops today do not have many parallelizable applications. The
object oriented nature of processes brings many advantages. Each process is an
object, and therefore the kernel controlling memory access can segment memory
such that each process has its own address space -- each object knows what its
address space is supposed to be. Each object or process knows what its
privileges are, and can transfer privileges to children or peer processes (if
allowed). Concurrency synchronization primitives are built into the OS and
objects, making it simple to build higher-level functions and programming of
scalable and parallel user applications.

Even exception handling is provided by the message-passing mechanisms. When it
generated an exception, the executable state of a process is sent to a special
``bail out'' mailbox which could belong to the OS or another process. This
sounds like it could be very robust and allow for creative uses of the system
for new libraries or small domain-specific languages. For example, like in
MINIX, there could be a ``resurrection server'' that handles software
exceptions from processes: when they fail, it restarts them.

The architecture of StarOS is interesting, but it is closely tied to the Cm*
hardware. The ideas sound like they were an inspiration for modern ideas in
high performance computing and OS kernel design.