1. SPIN: Design Contention between Safety-Extensibility-Performance Review of Extensibility, Safety and Performance in the SPIN Operating System By Lewis Coates

2. Some Preamble Discusses an operating system on a DEC Alpha Written circa 1994-95, so in competition with L3 and MACH Although Mach would be abandoned almost as this paper was coming out Modula 3 appeared roughly 1988, so was a somewhat mature Programming language DEC was acquired in 1998 which would largely make both Modula 3 and the Alpha (and by extension SPIN) irrelevant.

3. Modula 3 Modula 3 is a (very) late successor to Pascal Very reminiscent of modern Java, or especially C# Much of the design decisions were leveraged in C# and more recent versions of Java Used to implement the Kernel, but code in the applications can be anything (a UNIX server was written in C…surprised? No? Bueller?) Was a major point of design decision

4. More Modula 3 Kernel relies on some data hiding properties of modules Strong, static typing (yes, I know that’s ambiguous) Automatic Storage management (Garbage Collection in common vernacular) Index bounds checks (and on error…?)

5. Way Too Much on Modula 3 Originally the team (all C coders) tried to make a new version of C that had garbage collection, objects, richer type system etc. etc. They Failed. Like everyone else. Switched to Modula 3 Because it has no noticeable performance degradation (citation needed) And because C programmers can learn it in 3 days (citation very much needed) “Although anecdotal, our experience has been that the portions of the SPIN kernel written in Modula-3 are much more robust and easier to understand than those portions written in C.”

6. Primary Goals Co-Location-for performance and safety Logical Protection domains (protected virtual memory spaces) Dynamic Call binding (fast system calls?)

7. No one has gotten the Holy Grail Yet Hydra-good performance and protection, terrible extensibility L3/other microkernels, excellent performance, great extensibility, questionable performance “little language” based extension-confusing and difficult Arbitrary code execution-fantastic performance, unparalleled extensibility, literally no protection Software fault isolation-not yet discovered (simultaneous with this paper) Pilot-written in MESA, relied on MESA for all programs in the system, not just Kernel. Extensibility great…if you force everyone to learn MESA MS-Dos-Got none of it in exchange for nothing

8. Capabilities The Kernel API is built around an abstraction called “capabilities Virtual memory system, for example Different protection domains to allow different extensions different levels of visibility Exposed as typed pointers to blocks of Can be externalized, each application has a table of indexes into the kernel, pass the index of the reference in the table corresponding to the service in the kernel

9. Protection Domains At the language level, not virtual memory Defines a set of names, symbols, etc. that can be referenced by anyone with access to this protection domain Safe if signed by kernel, or asserted (C libraries, binary blobs) Domains can be intersecting, disjoint

10. Extensibility Scheduler, Page manager etc. Events and handlers, events messages, handlers receivers Handlers registered at a dispatcher Event is a procedure exported from an interface, handlers are procedures of same type Pre-emptive, handlers can’t take over Raising an event = calling a procedure Delegation of authority for control Guards are a finer granularity then by name, useful i.e. in TCP/IP Asynchronous, multiple handlers, you name it, probably possible

11. Core services Manage memory Manage processes Pretty much it Fairly vanilla setup Lot’s of small operations

12. Extensible Memory Management Pretty much the same as any other Storage, naming, translation are the three services Use these to make whatever you want (for example UNIX like address space semantics)

13. Extensible Thread Management Every application can declare it’s own scheduler and thread library, which runs in kernel space Each context a strand, like a thread context, but no kernel state other than a name Synchronization and thread management of the kernel, is the kernels (safety) Checkpoint, resume, block, unblock

14. Trusted Services Core services are “trusted” Allowed to control the Kernel Access hardware extension can blow themselves up by corrupting thread definitions etc. Isolated to that extension

15. Performance System Size Microbenchmarks Networking End to end performance DEC Alpha, 133 MHZ, AXP 3000/4000, 64 MB ram, 512kb cache, 1 gb diskdrive, 10mb/sec ethernet, 155 mb/sec ATM adapter(?) Single user mode

16. Enter the Strawman These performance characteristics are basically useless as presented Difficult for me to extract meaningful information and comparisons to L3/L4 since they don’t post syscall times, or other competing Items on the same hardware Basically saying they are doing better than people who didn’t do very well

17. Microbenchmarks 65K lines of code 447 kb Protected Communication is faster than either OSF/1 (by a lot) or Mach (by some), and system calls are on par with OSF/1 (Mach is almost twice as slow) Protected in kernel call (fast), not available in either competitor

18. Microbenchmarks Extended Thread management in Kernel was dramatically faster for Fork Join than either OSF/1 and MACH, basically across the board by a factor of 5-10 Ping Pong was also dramatically faster (3-5x) Showed that you can use a user level thread library without performance penalty in user space Memory is dominatingly faster because of application specifc system calls for virtual memory, and in kernel protectd procedure

19. Networking Once again dramatically faster then the competition across the board in latency, bandwidth, throughput, scalability Basically a godsend to everyone because it’s so perfect Totally not because it’s simply better implemented (for example, supports DMA)

20. Other Dispatcher is a huge hotspot on all event performance paths Particularly with guards Garbage collector has specific design parameters (not allocating lots of little objects) Extensions relatively small (which is nice) Also quite modular