Extensibility, Safety, and Performance in the SPIN Operating System

One-line summary: This paper presents SPIN, an extensible operating system that can be dynamically specialized to meet the needs of individual applications.

Overview/Main Points

• 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:

    1. Co-location : Extensions are dynamically linked into the kernel space.
    2. Enforced modularity: Modula-3 magic... (interface boundaries, modules) Provides cheap isolation at compile time.
    3. Logical protection domains: Extensions are protected from each other but dynamically linked in a way that allows low-cost cross-domain communication.
    4. 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").

• Architecture:
  • 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).

• Performance
  • 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 favorably.

  • Reasonable and realistic application examples are presented (some with performance statistics), including TCP/IP (with redirection), a network video system, and an http server.

Conclusions

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.

Questions

How does the system perform in benchmarks when multiple users are running?