Extensibility, Safety and Performance in the SPIN Operating System

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 Department of Computer Science and Engineering University of Washington Seattle, WA 98195 Abstract purpose network protocol implementations are frequently in- adequate for supporting the demands of high performance This paper describes the motivation, architecture and per- parallel applications [von Eicken et al. 92]. Other applica- formance of SPIN, an extensible operating system. SPIN tions, such as multimedia clients and servers, and realtime provides an extension infrastructure, together with a core and fault tolerant programs, can also present demands that set of extensible services, that allow applications to safely poorly match operating system services. Using SPIN,an change the operating system's interface and implementation. application can extend the operating system's interfaces and Extensions allow an application to specialize the underly- implementations to provide a better match between the needs ing operating system in order to achieve a particular level of the application and the performance and functional char- of performance and functionality. SPIN uses language and acteristics of the system. link-time mechanisms to inexpensively export ®ne-grained interfaces to operating system services. Extensions are written in a type safe language, and are dynamically linked into 1.1 Goals and approach the operating system kernel. This approach offers extensions The goal of our research is to build a general purpose op- rapid access to system services, while protecting the operat- erating system that provides extensibility, safety and good ing system code executing within the kernel address space. performance. Extensibility is determined by the interfaces SPIN and its extensions are written in Modula-3 and run on to services and resources that are exported to applications; DEC Alpha workstations. it depends on an infrastructure that allows ®ne-grained access to system services. Safety determines the exposure of 1 Introduction applications to the actions of others, and requires that access be controlled at the same granularity at which extensions are SPIN is an operating system that can be dynamically spe- de®ned. Finally, good performance requires low overhead cialized to safely meet the performance and functionality re- communication between an extension and the system. quirements of applications. SPIN is motivated by the need to The design of SPIN re¯ects our view that an operating support applications that present demands poorly matched by system can be extensible, safe, and fast through the use of an operating system's implementation or interface. A poorly language and runtime services that provide low-cost, ®ne- matched implementation prevents an application from work- grained, protected access to operating system resources. ing well, while a poorly matched interface prevents it from Speci®cally, the SPIN operating system relies on four tech- working at all. For example, the implementations of disk niques implemented at the level of the language or its runtime: buffering and paging algorithms found in modern operating systems can be inappropriate for database applications, Co-location. Operating system extensions are dynam- resulting in poor performance [Stonebraker 81]. General ically linked into the kernel virtual address space. Co- location enables communication between system and This research was sponsored by the Advanced Research Projects Agency, the National Science Foundation (Grants no. CDA-9123308 and extension code to have low cost. CCR-9200832) and by an equipment grant from Digital Equipment Corpo- ration. Bershad was partially supported by a National Science Foundation Enforced modularity. Extensions are written in Modula- Presidential Faculty Fellowship. Chambers was partially sponsored by a 3 [Nelson 91], a modular programming language for National Science Foundation Presidential Young Investigator Award. Sirer was supported by an IBM Graduate Student Fellowship. Fiuczynski was which the compiler enforces interface boundaries be- partially supported by a National Science Foundation GEE Fellowship. tween modules. Extensions, which execute in the kernel's virtual address space, cannot access memory or execute privileged instructions unless they have been given explicit access through an interface. Modularity enforced by the compiler enables modules to be isolated to the client'sscreen. Using SPIN the server de®nes an exten- from one another with low cost. sion that implements a direct stream between the disk and the network. The client viewer application installs an extension Logical protection domains. Extensions exist within into the kernel that decompresses incoming network video logical protection domains, which are kernel names- packets and displays them to the video frame buffer. paces that contain code and exported interfaces. Inter- faces, which are language-level units, represent views on system resources that are protected by the operat- 1.3 The rest of this paper ing system. An in-kernel dynamic linker resolves code in separate logical protection domains at runtime, en- The rest of this paper describes the motivation, design, and abling cross-domain communication to occur with the performanceof SPIN. In thenext section wemotivatetheneed overhead of a procedure call. for extensible operating systems and discuss related work. In Section 3 we describe the system's architecture in terms of its Dynamic call binding. Extensions execute in response protection and extension facilities. In Section 4 we describe to system events. An event can describe any potential the core services provided by the system. In Section 5 we action in the system, such as a virtual memory page fault discuss the system's performance and compare it against that or the scheduling of a thread. Events are declared within of several other operating systems. In Section 6 we discuss interfaces, and can be dispatched with the overhead of a our experiences writing an operating system in Modula-3. procedure call. Finally, in Section 7 we present our conclusions. Co-location, enforced modularity, logical protection domains, and dynamic call binding enable interfaces to be de- ®ned and safely accessed with low overhead. However, these 2 Motivation techniques do not guarantee the system's extensibility. Ulti- mately, extensibility is achieved through the system service Most operating systems are forced to balance generality and interfaces themselves, which de®ne the set of resources and specialization. A general system runs many programs, but operations that are exported to applications. SPIN provides may run few well. In contrast, a specialized system may a set of interfaces to core system services, such as memory run few programs, but runs them all well. In practice, most management and scheduling, that rely on co-location to ef- general systems can, with some effort, be specialized to ad- ®ciently export ®ne-grained operations, enforced modularity dress the performance and functional requirements of a par- and logical protection domains to manage protection, and ticular application's needs, such as interprocess communica- dynamic call binding to de®ne relationships between system tion, synchronization, thread management, networking, vir- components and extensions at runtime. tual memory and cache management [Draves et al. 91, Ber- shad et al. 92b, Stodolsky et al. 93, Bershad 93, Yuhara et al. 94, Maeda & Bershad 93, Felten 92, Young et al. 87, Harty 1.2 System overview & Cheriton 91, McNamee & Armstrong 90, Anderson et al. The SPIN operating system consists of a set of extension 92, Fall & Pasquale 94, Wheeler & Bershad 92, Romer et al. services and core system services that execute within the 94, Romer et al. 95, Cao et al. 94]. Unfortunately, exist- kernel's virtual address space. Extensions can be loaded ing system structures are not well-suited for specialization, into the kernel at any time. Once loaded, they integrate often requiring a substantial programming effort to affect themselvesinto theexisting infrastructureand providesystem even a small change in system behavior. Moreover, changes services speci®c to the applications that require them. SPIN intended to improve the performance of one class of appli- is primarily written in Modula-3, which allows extensions cations can often degrade that of others. As a result, system to directly use system interfaces without requiring runtime specialization is a costly and error-prone process. conversion when communicating with other system code. An extensible system is one that can be changed dynam- AlthoughSPIN relies on language features to ensure safety ically to meet the needs of an application. The need for within the kernel, applications can be written in any language extensibility in operating systems is shown clearly by sys- and execute within their own virtual address space. Only tems such as MS-DOS, Windows, or the Macintosh Operat- code that requires low-latency access to system services is ing System. Although these systems were not designed to be written in the system's safe extension language. For exam- extensible, their weak protection mechanisms have allowed ple, we have used SPIN to implement a UNIX operating application programmers to directly modify operating sys- system server. The bulk of the server is written in C, and tem data structures and code [Schulman

Load more