1. Extensibility, Safety and Performance in the SPIN Operating System Dave Camarillo

2. What is SPIN? SPIN is an experimental operating system that uses a non-traditional structure to provide extensibility, safety and performance. SPIN allows for modules to interact with the OS so as to gain performance benefits of specialization and retain the generalization of a generic OS.

3. Why was SPIN Created? Most OS’s can run many applications with acceptable performance. Other OS’s can run a few applications with excellent performance. It’s difficult or impossible to find OS’s that can do both (but it would be nice).

4. Why was SPIN Created? (cont.) An attempt to make a general purpose OS that can run all applications well. Provide a OS that is extensible so new functionality can be added with the best performance characteristics.

5. Language for Security SPIN uses language functionality to for security. Relies on Modula-3’s interfaces, type safety and automatic storage management. All code is implemented within modules, which are type checked at compile time and can only be manipulated thru safe interfaces that are published.

6. Protection Domains A protection domain consists of a set of names and/or symbols that can be referenced by code with access to that domain. Only Modula-3 signed modules are given un-checked access to a protection domain. Modules that are not signed are checked by assertion (more time consuming, but ensuring safety).

7. Module/Domain Exporting Module creates an explicit domain. Modules uses the in-kernel name server to advertise it’s availability. Modules can register an authorization method, allowing a module to restrict access to it’s functionality.

8. The Extension Model Event listeners can be registered by modules with the event dispatcher. When an event occurs, the dispatcher will call the registered procedure in the module to handle the event.

9. Extensions Processes install additional extensions into the kernels address space to avoid the future need to make extra kernel calls. Kernel verifies the Modula-3 signatures of the extensions.

10. Standard Extensions in SPIN Memory Management Thread Management

11. Memory Management Three Components: physical storage, naming, translation Physical Address Service controls the use and allocation of physical pages. Virtual Address Service creates virtual addresses indicating their address space, length and identifier. Translation Service expresses virtual to real address mappings, utilizing the MMU

12. Thread Management SPIN doesn’t define thread model, instead defines structure upon which different threading models can be implemented. SPIN provides Strands They’ve used OSF/1 kernel threads, C-Threads and Modula-3 threads in SPIN.

13. SPIN Performance System Size Micro benchmarks Networking End-to-end performance

14. Performance: Micro Benchmarks, 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

15. Performance: Micro Benchmarks, Threads Thread performance in SPIN was better then that of OSF/1 and Mach in the ping-pong and fork-join tests.

16. Performance: Micro Benchmarks, Virtual Memory SPIN uses kernel extensions to define application-specific system calls for VM management. The multiple application-kernel interactions are reflected to the application by fast in-kernel modules, avoiding the need to use traps or messages.

17. Performance, Networking, Latency & Bandwidth SPIN shows better network latency and bandwidth performance characteristics then OSF/1. Largely due to processing of network traffic within kernel as opposed to in application.

18. Performance, End to End 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.

19. Conclusions The use of co-location, loadable modules, protection domains and dynamic call binding can allow an OS to be minimal, flexible, extensible and efficient.