Transcript ppt

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)
It allows applications to change OS
– Interface
– Implementation

It uses languages and link-time mechanisms
– To export fine grain interfaces


Type safe language used for extensions
Extensions dynamically linked into OS kernel
Introduction



Desire: To match applications with operating
system implementation or interface
[Von Eicken et al ’92]
– High performance parallel apps don’t work
well with network protocol implementations.
[Stonebraker ’81]
– Database apps perform poorly with disk
buffering/paging algorithms in OS
Goals and Approach


Spin relies on four techniques:
– Co-location
– Enforced modularity
– Logical protection domains
– Dynamic call binding
The language and runtime provide
support for these techniques
SPIN System Overview




Executes in kernel’s virtual address
space
Provides a set of extension and core
system services
Dynamically loads into kernel
Written in Modula-3
Motivation


System structures are not setup well
for specialization and can be costly
Why extensible?
– The system can be dynamically be
changed to meet needs of a specific
application
Related Work





Hydra [Wulf et al ’81]
Microkernels [Bershad et al ‘90]
Cross-Domain Communication
[Hamilton & Kourgiouris ’93]
“Little Languages” [Lee et al ’94]
Code install in kernel at runtime
[Heidemann & Popek ’94]
Related Work



Software Fault Isolation [Wahbe et al
’93]
Aegis [Engler et al ’95]
Systems using language features (like
SPIN) to extend operating system
services [Cooper et al ’91]
SPIN Architecture
Two Models
Protection
Extension
Protection Model


Controls set of operations that can be
used with resources
Capabilites, what are they?
– Definition:

An unforged reference to a resource
– Implemented using Pointers
– Pointer Definition:

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
MODULE
Console;
Gatekeeper;
Console;
(* (*
An A
Anclient
Implementation
Interface.
*)
*)
module *)
TYPE T Console;
IMPORT
<: REFANY; (* Read as “Console.T is opaque” *)
(* The implementation of Console.T *)
CONST
TYPE
VAR
c:
Buf
InterfaceName
Console.T;
= ARRAY [0..31]
(*=A“ConsoleService”
capability
OF CHAR; for *)
REVEAL
(* A global
T = BRANDED
name (*
*)
REFthe
RECORD
console
(* Tdevice
is a pointer
*)
*)
inputQ: Buf;
(* to a record *)
PROCEDURE
outputQ:
Open():
IntruderAlert()
Buf;
T;
=
(*
BEGIN
Open
(* device
returnsspecific
a capability
info *)
for the console. *)
PROCEDURE
END;
c := Write(t:
Console.Open();
T; msgs: TEXT);
PROCEDURE
Console.Write(c,
Read(t: VAR;“Intruder
msg: TEXT);
Alert”);
PROCEDURE
(*
Implementations
Console.Close(c);
Close(t: of
T);interface functions *)
ENDhave
(*
END
Console;
IntruderAlert;
direct access to the revealed type *)
PROCEDURE Open(): T = …
END Console;
BEGIN
END Gatekeeper;
Protection Domains


Generally, it is the set of accessible
names available to an execution context
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
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
– controlled communication between
extension and system

As an example, extension could…
– Monitor system activity
– Send peformance information to
applications

Extensions = Events + Handlers
More about Extensions…
Extension
Message sent to announce
change in system state
or
To request service
Event
Registers
Event Handler with
Event Name
Central
Dispatcher
If allowed,
GUARD can be
associated with
handler
Other
Modules
Can request to install addl
handlers or replace
primary handler
Passes
Event
Name
Primary
Implementation
Module
SPIN Core Services

Extensible Memory Management
– Physical storage
– Naming
– Translation

Extensible Thread Management
– Strands
Physical Address Service


Controls use and allocation of pages
Allocate event
– Requests physical memory
– Size specified
– Optional attributes specified

Deallocate event
– Given pointer p to memory, frees physical
memory

Reclaim event
– Reclaims a candidate page
Virtual Address Service


Allocates capabilities for virtual
addresses
Capability’s referent has
– Virtual address
– Length
– Address Space Identifier

Interface has procedures Allocate and
Deallocate
Translation Service


Expresses relationship between virtual
address and physical memory
Interprets 2 references
– to virtual addresses
– to physical addresses


Constructs a map between them
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
 Microbenchmarks
 Networking
 End-to-end performane
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
– Measures 565 μs

50 GUARDs register interest in UDP pkt
and all GUARDs evaluate to false
– Measures 585 μs

These same 50 GUARDs evaluate to true
– Measures 637 μs
Other Issues:
Automatic Storage Management


SPIN uses trace-based mostly-copying
garbage collector
None of previous measurement
benchmarks change if garbage
collection disabled
Other Issues: Extension Sizes
Conclusions



SPIN achieves performance, without
sacrificing safety
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