Extensibility, Safety and Performance in the SPIN Operating System B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. E. Fiuczyski, D. Becker, C. Chambers, S. Eggers Presenter: Judy Fischbach

Contributions New extensible OS system (SPIN) New extensible OS system (SPIN) It allows applications to change OS It allows applications to change OS –Interface –Implementation It uses languages and link-time mechanisms It uses languages and link-time mechanisms –To export fine grain interfaces Type safe language used for extensions Type safe language used for extensions Extensions dynamically linked into OS kernel Extensions dynamically linked into OS kernel

Introduction Desire: To match applications with operating system implementation or interface Desire: To match applications with operating system implementation or interface [Von Eicken et al ’92] [Von Eicken et al ’92] –High performance parallel apps don’t work well with network protocol implementations. [Stonebraker ’81] [Stonebraker ’81] –Database apps perform poorly with disk buffering/paging algorithms in OS

Goals and Approach Spin relies on four techniques: Spin relies on four techniques: –Co-location –Enforced modularity –Logical protection domains –Dynamic call binding The language and runtime provide support for these techniques The language and runtime provide support for these techniques

Goals and Approach Spin relies on four techniques: Spin relies on four techniques: –Co-location –Enforced modularity –Logical protection domains –Dynamic call binding The language and runtime provide support for these techniques The language and runtime provide support for these techniques

SPIN System Overview Executes in kernel’s virtual address space Executes in kernel’s virtual address space Provides a set of extension and core system services Provides a set of extension and core system services Dynamically loads into kernel Dynamically loads into kernel Written in Modula-3 Written in Modula-3

Motivation System structures are not setup well for specialization and can be costly System structures are not setup well for specialization and can be costly Why extensible? Why extensible? –The system can be dynamically be changed to meet needs of a specific application

Related Work Hydra [Wulf et al ’81] Hydra [Wulf et al ’81] Microkernels [Bershad et al ‘90] Microkernels [Bershad et al ‘90] Cross-Domain Communication [Hamilton & Kourgiouris ’93] Cross-Domain Communication [Hamilton & Kourgiouris ’93] “Little Languages” [Lee et al ’94] “Little Languages” [Lee et al ’94] Code install in kernel at runtime [Heidemann & Popek ’94] Code install in kernel at runtime [Heidemann & Popek ’94]

Related Work Hydra [Wulf et al ’81] Hydra [Wulf et al ’81] Microkernels [Bershad et al ‘90] Microkernels [Bershad et al ‘90] Cross-Domain Communication [Hamilton & Kourgiouris ’93] Cross-Domain Communication [Hamilton & Kourgiouris ’93] “Little Languages” [Lee et al ’94] “Little Languages” [Lee et al ’94] Code install in kernel at runtime [Heidemann & Popek ’94] Code install in kernel at runtime [Heidemann & Popek ’94]

Related Work Software Fault Isolation [Wahbe et al ’93] Software Fault Isolation [Wahbe et al ’93] Aegis [Engler et al ’95] Aegis [Engler et al ’95] Systems using language features (like SPIN) to extend operating system services [Cooper et al ’91] Systems using language features (like SPIN) to extend operating system services [Cooper et al ’91]

SPIN Architecture Two Models ProtectionExtension

Protection Model Controls set of operations that can be used with resources Controls set of operations that can be used with resources Capabilites, what are they? Capabilites, what are they? –Definition: An unforged reference to a resource An unforged reference to a resource –Implemented using Pointers –Pointer Definition: A reference to a memory block whose type is defined within an interface A reference to a memory block whose type is defined within an interface

Example: Definition and use of interfaces/capabilities in SPIN ref: Figure 1 of SPIN paper INTERFACE Console; (* An Interface. *) TYPE T <: REFANY; (* Read as “Console.T is opaque” *) CONST InterfaceName = “ConsoleService” (* A global name *) PROCEDURE Open(): T; (* Open returns a capability for the console. *) PROCEDURE Write(t: T; msgs: TEXT); PROCEDURE Read(t: VAR; msg: TEXT); PROCEDURE Close(t: T); END Console; MODULE Console; (* An Implementation module *) (* The implementation of Console.T *) TYPE Buf = ARRAY [0..31] OF CHAR; REVEAL T = BRANDED REF RECORD (* T is a pointer *) inputQ: Buf; (* to a record *) outputQ: Buf; (* device specific info *) END; (* Implementations of interface functions *) (* have direct access to the revealed type *) PROCEDURE Open(): T = … END Console; MODULE Gatekeeper; (* A client *) IMPORT Console; VAR c: Console.T; (* A capability for *) (* the console device *) PROCEDURE IntruderAlert() = BEGIN c := Console.Open(); Console.Write(c, “Intruder Alert”); Console.Close(c); END IntruderAlert; BEGIN END Gatekeeper;

Protection Domains Generally, it is the set of accessible names available to an execution context Generally, it is the set of accessible names available to an execution context But different for SPIN But different for SPIN –Name and protection interface is at language level, not at virtual memory –A protection domain defines the set of names that can be referenced by code with access to that domain

More about Domains Domain can be intersecting or disjoint Domain can be intersecting or disjoint Operations Operations –Create: Initializes domain –Resolve: Matches symbols between target and those exported from source –Combine: Creates linkable namespaces that consist of union of existing domains

Domain Interface ref: Figure 2 of SPIN paper INTERFACE Domain; TYPE T <: REFANY; (* Domain.T is opaque *) PROCEDURE Create (coff:CoffFile.T):T; PROCEDURE CreateFromModule():T; PROCEDURE Resolve(source, target: T); PROCEDURE Combine (d1, d2: T): T; END Domain.

Extension Model Provides Provides –controlled communication between extension and system As an example, extension could… As an example, extension could… –Monitor system activity –Send peformance information to applications Extensions = Events + Handlers Extensions = Events + Handlers

More about Extensions… More about Extensions… Central Dispatcher Extension Registers Event Handler with Event Name Message sent to announce change in system state or To request service Event Primary Implementation Module Other Modules Passes Event Name If allowed, GUARD can be associated with handler Can request to install addl handlers or replace primary handler

SPIN Core Services Extensible Memory Management Extensible Memory Management –Physical storage –Naming –Translation Extensible Thread Management Extensible Thread Management –Strands

Physical Address Service Controls use and allocation of pages Controls use and allocation of pages Allocate event Allocate event –Requests physical memory –Size specified –Optional attributes specified Deallocate event Deallocate event –Given pointer p to memory, frees physical memory Reclaim event Reclaim event –Reclaims a candidate page

Virtual Address Service Allocates capabilities for virtual addresses Allocates capabilities for virtual addresses Capability’s referent has Capability’s referent has –Virtual address –Length –Address Space Identifier Interface has procedures Allocate and Deallocate Interface has procedures Allocate and Deallocate

Translation Service Expresses relationship between virtual address and physical memory Expresses relationship between virtual address and physical memory Interprets 2 references Interprets 2 references –to virtual addresses –to physical addresses Constructs a map between them Constructs a map between them Installs this map in the MMU Installs this map in the MMU

Strands ref: Figure 4 of SPIN paper INTERFACE Strand; TYPE T <: REFANY; (* Strand.T is opaque *) PROCEDURE Block (s:T); PROCEDURE UnBlock(s:T); PROCEDURE Checkpoint(s:T); PROCEDURE Resume (s:T); END Domain.

System Performance Four Perspectives: System Size System Size Microbenchmarks Microbenchmarks Networking Networking End-to-end performane End-to-end performane

System component sizes System component sizes

Microbenchmarks: Protected communication

Microbenchmarks: Thread Management

Microbenchmarks: Virtual Memory

Structure of Network Stacks

Microbenchmarks: Network Latency and Bandwidth Ethernet and ATM applications using UDP/IP for both OSF/1 and SPIN

Microbenchmarks: Network Protocol Forwarding

End to End Performance

Other Issues: Scaling and Dispatch Roundtrip Ethernet latency Roundtrip Ethernet latency –Measures 565 μs 50 GUARDs register interest in UDP pkt and all GUARDs evaluate to false 50 GUARDs register interest in UDP pkt and all GUARDs evaluate to false –Measures 585 μs These same 50 GUARDs evaluate to true These same 50 GUARDs evaluate to true –Measures 637 μs

Other Issues: Automatic Storage Management SPIN uses trace-based mostly-copying garbage collector SPIN uses trace-based mostly-copying garbage collector None of previous measurement benchmarks change if garbage collection disabled None of previous measurement benchmarks change if garbage collection disabled

Other Issues: Extension Sizes

Conclusions SPIN achieves performance, without sacrificing safety SPIN achieves performance, without sacrificing safety Enables an efficient way to extend services along with basic set of core services Enables an efficient way 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 Programming languages with the appropriate feature support can be used to construct future operating systems