EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM Brian N. Bershad, Stefan Savage, Przemysław Pardyak, Emin G¨un Sirer, Marc E. Fiuczynski, David Becker, Craig Chambers, Susan Eggers Presenter: Myeonwoo Lim

OUTLINE Overview Motivation SPIN Architecture Core Services Performance Conclusions

OVERVIEW What is spin? SPIN is a dynamically extensible operating system that allows user applications to safely change the operating system's interface and implementation. Extensions are linked into the operating system kernel at application runtime, enabling them to access system services with low overhead.

OVERVIEW Goals SPIN combines research in systems, languages, and compilers to achieve the three fundamental goals of modern operating systems. Extensibility Applications must be able to extend kernel functionality. Safety Access to system resources must be controlled at the same granularity at which extensions are defined Performance Requires low-overhead in the extension mechanisms Application performance is the end goal

OVERVIEW Approach for the goals Co-location Enforced modularity Extensions live in kernel space Enforced modularity Extensions are written in Modula-3, which enforces interface boundaries between modules. Logical protection domains Namespaces inside kernel, intra-domain communication possible at cost of procedure call Dynamic call binding Extensions execute in response to system events.

MOTIVATION SPIN is motivated by the need to support applications that present demands poorly matched by an operating system’s implementation or interface. Related Work Hydra [Wulf et al ‘81] Microkernels [Bershad et al ‘90] Cross-Domain Communication [Hamilton & Kourgiouris] “Little Languages” [Lee et al ‘94] Code install in kernel at runtime [Heidemann & Popek ‘94] Software fault isolation [Wahbe et al. 93] Aegis[Engler et al. 95]

SPIN STRUCTURE SPIN architecture provides a software infrastructure for safely combining system and application code. Protection Model supports efficient, fine-grained access control of resources Extension Model enables extensions to be defined at the granularity of a procedure call Relevant properties of Modula-3 Interfaces, type safety, automatic storage management, objects, generic interfaces, threads, and exceptions.

SPIN STRUCTURE PROTECTION MODEL Controls the set of operations that can be applied to resources. Capabilities: Unforgeable reference to a resource. All kernel resources are referenced by capabilities Resources are protected to ensure that extension reference the resources to which they have been given access SPIN implements capabilities directly using pointers A pointer can be passed from the kernel to user-level applications as externalized references

SPIN STRUCTURE PROTECTION MODEL CONT’D. Protection domains Defines a set of names, or program symbols, which can be referenced by code with access to the domain. A domain, named by a capability, is used to control dynamic linking, and corresponds to one or safer object files. Operations Create: create a new domain Resolve: dynamic linking Combine: create a new aggregate domain

SPIN STRUCTURE EXTENSION MODEL Provides a controlled communication facility between extensions and the base system Extensions in SPIN are defined in terms of events and handlers The primary right to handle an event is restricted to the default implementation module for the event, which is the module that statically exports the procedure named by the event Other modules may request that the dispatcher install additional handlers or even remove the primary handler Dispatcher contacts primary implementation module. If denied installation falls If allowed, the implementation module can provide a guard to be associated with the handler

CORE SERVICES SPIN provides a set of core services that manage memory and processor resources The core services provided by SPIN are Extensible memory management Extensible thread management

CORE SERVICES EXTENSIBLE MEMORY MANAGEMENT A memory management system is responsible for the allocation of virtual addresses, physical addresses, and mapping between the two. Components Physical address service: controls use and allocation of physical pages. Virtual address service: allocates capabilities for virtual addresses. Translation service: expresses relationship between physical and virtual addresses.

CORE SERVICES EXTENSIBLE THREAD MANAGEMENT Application can provide its own thread package and scheduler that executes within the kernel. SPIN doesn’t define thread model, instead defines structure upon which different threading models can be implemented. SPIN use strands. Operations: Block Unblock Checkpoint Resume

PERFORMANCE Platform SPIN runs on DEC Alpha platforms Measurements DEC Alpha 133Mhz AXP 3000/400 works stations Comparison system MEC OSF/1 V2.1 (monolithic operating system) Mach 3.0

PERFORMANCE Mirobenchmarks: Protected communication SPIN performed better for both system calls and cross-address calls. It’s in-kernel calls were significantly faster then either two of the other methods

PERFORMANCE Microbenchmarks: Thread Management Thread performance in spin was better than that of OSF/1 and Mach in the ping-pong and fork-join tests.

PERFORMANCE Microbenchmarks: Virtual Memory Reasons for outperform SPIN uses kernel extensions to define application specific system calls for virtual memory management. Virtual memory event is reflected to the application through a fast in-kernel protected procedure call

PERFORMANCE Networking: Network Latency and Bandwidth SPIN shows better network latency and bandwidth performance characteristics then OSF/1. The application code executes in the kernel, where it has low-latency access to both the device and data.

PERFORMANCE End to End Performance SPIN utilizes half of the hardware as compared to OSF/1 for the same client load. SPIN tries to avoid double buffering between OS and application.

CONCLUSIONS SPIN achieves performance in an extensible system without sacrificing safety. SPIN provides a set of efficient mechanisms to extend services along with basic set of core services. Programming languages with the appropriate feature support can be used to construct future operating systems

QUESTIONS?