Extensibility, Safety, and Performance in the SPIN Operating System
Bershad, Savage, Pardyak, Sirer, Fiuczynski, Becker, Chambers, and Eggers
This paper presents SPIN, an extensible operating system that can be
dynamically specialized to meet the needs of individual applications.
- General Description:
- The interfaces and/or implementation of general operating
systems are seldomly optimal for applications. SPIN is
general in that it provides extensibility, safety, and good
performance, but also customizable in that it provides low-cost,
fine-grained, protected access to OS resources, through:
- Co-location : Extensions are dynamically linked into the
- Enforced modularity: Modula-3 magic... (interface
boundaries, modules) Provides cheap isolation at compile time.
- Logical protection domains: Extensions are
protected from each other but dynamically linked in a way that allows
low-cost cross-domain communication.
- Dynamic call binding: Extensions are accessed
through events and handlers associated (at run-time) with
system events (low overhead).
- Language features ensure safety within the kernel.
However, applications can be written in any language and
executed within their own virtual address space. (If one
wants these in the kernel, they must be "trusted").
- Modula 3 provides : static type-checking/type safety, dynamic linking,
support for interfaces, automatic storage management, objects, generic
interfaces, threads, and exceptions. Naming and the
protection interface are in the language (not in virtual memory system).
- Capabilities are unforgeable references to resources
(i.e. system objects, interfaces, collections of interfaces).
These are implemented using pointers, with the compiler ensuring that
they cannot be forged, dereferenced improperly, or accessed by
the unprivileged masses.
- Extensions are defined in terms of events and handlers, which
are registered through a central dispatcher. The right to
call a procedure = the right to raise the event named by the procedure
(must have access to the interface/domain).
- The module that exports the procedure is the default
implementation. Other modules may attempt to install
additional handlers or remove the primary implementation.
Handlers can be constrained in their execution (levels of trust).
- Guards can be associated with handlers to restrict access at
a finer granularity than events. (IP/protocol types example).
- Core Services
- Used to manage memory and processor resources.
- Extensible memory management: fast, fine-grained
control over physical and virtual memory resources.
- Extensible thread management: Applications are able
to provide their own thread packages and schedulers within the kernel.
(The kernel defines the structure upon with the implementation of
threads runs, but does not define the thread model for
applications). Scheduling and synchronization within the
kernel is handled completely by the kernel, using Modula-3 threads.
- Global scheduler is replaceable by trusted admins
(currently round-robin, preemptive, priority policy).
- In comparison to Mach and OSF/1, protected communication is
much cheaper (from 20% to 800%, respectively). The thread
implementation and virtual memory management also perform
- Reasonable and realistic application examples are presented
(some with performance statistics), including TCP/IP (with
redirection), a network video system, and an http server.
Spin seems to offer good performance, extendibility, and fine
grain access to resources while maintaining safety. This flexibility
is impressive, and clearly a win for applications with specific needs
not addressed sufficiently by general operating systems.
These features come with a price, however - the system depends
very heavily upon Modula 3, which may impose limitations upon
application writers and present hidden dangers.
How exactly is access to objects controlled? Are there access lists
that the compiler uses to restrict application rights?
How does the system perform in benchmarks when multiple users are
Back to index