Extensibility, Safety and Performance in the SPIN Operating System

What kind of paper is this?

• Describes a system.
• Argues that you can have all three (extensibility, safety, and performance) in a single system.

The Big Idea

• Extensible systems are good: better able to match the needs of applications with the system.
• Use safe language for much of the protection.
• Export fine-grain interfaces.

Goals

• Provide the big three: extensibility, safety, and performance.
• Mechanisms
  1. Co-location: put stuff into the kernel (low cost communication).
  2. Encorced modularity: take advantage of Modula-3. Provides clean interfaces, restricts execution, does a lot checking at compile time.
  3. Logical protection domains: use kernel-namespaces instead of hardware protection domains.
  4. Dynamic call binding: raise events and execute extensions in response to these events.

SPIN Architecture

• Protection

  • Capability-based.
  • Language provides the implementation (pointers are typed).
  • A protection domain is a set of names available to a thread of execution.
  • Can merge domains.

• Extensibility

  • Register a handler for an event.
  • In most cases, performance is a function call.
  • Can raise any event you can name.
  • Guards restrict access to handlers.
  • Guards are essentially predicates.
  • Can have multiple handlers for an event.

• Core Services

  • These are services provided by SPIN with appropriate places to which to attach extensions.
  • Memory Management
    • Decomposed into three components: physical storage, naming, translation
    • Each component can be extended individually.
    • Physical storage: controls use and allocation of pages.
    • Naming: responsible for capabilities.
    • Translation: expresses relationship between physical and virtual. Raises events associated with traditional MMU exceptions.
    • Note that this model does not explicitly support address spaces; they are extensions that you build into this model.
  • Thread Management
    • Provides interfaces for scheduling, concurrency, and synchronization.
    • Allows applications to implement own kernel thread package.
    • Threads implemented on strands: like a thread, but minimal kernel state (only a name).
    • Key interfaces: block and unblock.
  • Note that core services are all trusted.
  • Extensions that use the core service interfaces incorrectly only damage themselves.

  Performance

  • Comparison with DEC OSF/1 and Mach.

  • Microbenchmarks

    Although these are microbenchmarks, the all take advantage of kernel extensions; bit of an odd comparison.
    1. Communication: canonical null procedure call.
       • System calls somewhat comparable to OSF/1
       • Cross-address space calls very fast (order of magnitude better than OSF/1; 10% better than Mach).
    2. Thread management
       • Offers both layered and integrated model (layered adds user-threads on top of mach threads; integrated exports c-threads)
       • Both models are significantly faster.
    3. Virtual Memory
       • Use Appel/Li benchmarks.
       • SPIN is using extensions designed to provide the memory management support.
       • Fast in-kernel communication avoids having to ping-pong back and forth between address spaces.
       • Result is significant improvement.

  • Networking

    • Used extensibility to implement a set of protocol stacks.
    • Video extension goes from network to framebuffer.
    • Note that SPIN provides improved latency, but equivalent bandwidth on Ethernet.
    • Extensibility used to provide protocol forwarding.

  • End to End

    • Use video setup to implement client viewer and server application.
    • Three kernel extensions for the server.
      1. local file system that reads video frames from disk.
      2. send video over network
      3. transform send into a multicast send.
    • Improved throughput by doing the multicast at the end.

  Lessons and Experience

  • Optimize the common case: normally there is only one signal handler and the dispatch is a function call.
  • Garbage collection is a win. Fortunately, most extensions do not allocate a lot of memory.
  • Extensions are small.
  • Modula-3 was a win; not as painful as anticipated.