and a lightweight, compiled runtime system for safe code. Like any system, Singularity also has its rough spots, and future research should aim to help resolve three troubling issues: the garbage collector in the kernel; the inconsistencies between Sing#’s two type systems; and C#’s incomplete type system.

Despite early concern in the project and ongoing external skepticism, our experience shows that high-performance system software can be built in a garbage-collected language. Singularity performed much better on basic micro and macro benchmarks than we originally anticipated, and when failing to perform well, problems were seldom attributable solely to garbage collection. Our experience confirms wisdom in the Java and Common Language Runtime communities that garbage collection obviates the need for strict memory accounting but does not eliminate the need for carefully managing memory in high-performance code.

The design of an optimal garbage collector for an OS kernel is an open question. The assumptions underlying generational collectors do not agree with the lifetime of many kernel objects that persist as long as the system or process exists. Reference counting, despite trade-offs involving cost and the inability to reclaim cyclic structures, is common in conventional operating systems and deserves reexamina-tion as a garbage-collection technique for safe kernels.

Sing#, the language of Singularity, supports two type systems: C# and data passed between processes. Data in a process is conventional C# objects, but data passed along channels lives in a distinct type system, limited to structs, not objects, and is governed by strict rules restricting references. This system allows static verification of channel contracts but exacts a price in programmer frustration and additional code for marshalling, unmar-shalling, and operations on the structs. Increased interoperability or, better, a unified type system would simplify the code for creating and manipulating messages. In addition, the channel contracts we used were not expressive enough to describe asynchronous interactions between processes.

Finally, C#, like many modern languages, does not provide convenient mechanisms for manipulating bit-level formatted data and inlined arrays found in device-control registers and network packets. Not adding this functionality to Sing# early in the Singular-ity-development project was an omission that continues to incur a penalty.

conclusion

Singularity is a small operating system we and a group of our colleagues at Microsoft Research built to demonstrate a nontrivial change in the standard practice of designing and constructing software. On today’s fast computers, it is no longer necessary to design systems around the lowest common denominator of assembly language or C, seeking performance to the detriment of essential system attributes (such as modularity and reliability). Singularity shows that modern, safe programming languages enable new system architectures that not only improve robustness but perform better in many circumstances than traditional approaches.

The lessons of Singularity are applicable far beyond the ground-up design of new systems; for example, manifests could be used in more traditional operating systems to describe dependencies, cross-process communication, and hardware access. Likewise, replacing in-process plug-ins with components in separate processes would improve the resilience of any system. Gradually incorporating safe languages, software isolation, and increased specification into existing systems offers cost-effective incremental improvement.

Source code for the Singularity system is available for noncommercial use at http://www.codeplex.com/sin-gularity.

acknowledgments

Singularity was the work of large
team of dedicated individuals: David
Tarditi, Bjarne Steensgaard, Qun-
yan Mangus, Mark Plesko, and Juan
Chen built the Bartok compiler and
runtime. Manuel Fähndrich, Song-
tao Xia, Sriram Rajamani, Jakob Re-
hof, Herman Venter, Rebecca Isaacs,
and Tim Harris worked on Sing# and
tools. Orion Hodson, Chris Hawblit-
zel, Steven Levi, Nick Murphy, Mark
Aiken, Derrick Coetzee, Ed Nightin-
gale, Brian Zill, and Richard Black
built portions of the operating sys-
tem. Ted Wobber, Martin Abadi, An-
drew Birrell, Ulfar Erlingsson, and
Dan Simon developed the security ar-
chitecture. In addition, more than 30
interns contributed heart, mind, and
hands to the project.

References

1. aiken, M., Fähndrich, M., Hawblitzel, C., Hunt, G., and larus, J.r. deconstructing process isolation. In Proceedings of the ACM SIGPLAN Workshop on Memory Systems Performance and Correctness (san Jose, Ca, oct.). aCM Press, new york, 2006, 1–10.

2. ball, t. and rajamani, s.K. the slaM toolkit. In Proceedings of the 13th Conference on Computer-Aided Verification (Paris, July). springer, 2001, 260–264.

3. barnett, M., Change, b.-y.e., deline, r., Jacobs, b., and leino, K.r. boogie: a modular reusable verifier for object-oriented programs. In Proceedings of the Fourth International Symposium on Formal Methods for Components and Objects (amsterdam, the netherlands, nov.). springer, 2005, 364–387.

4. bershad, b.n., savage, s., Pardyak, P., sirer, e.G., Fiuczynski, M., becker, d., eggers, s., and Chambers, C. extensibility, safety and performance in the sPIn operating system. In Proceedings of the 15th ACM Symposium on Operating Systems Principles (Copper Mountain resort, Co, dec.). aCM Press, new york, 1995, 267–284.

5. Chou, a., yang, J., Chelf, b., Hallem, s., and engler, d. an empirical study of operating systems errors. In Proceedings of the 18th ACM Symposium on Operating Systems Principles (Chateau lake louise, banff, Canada, oct.). aCM Press, new york, 2001, 73–88.

6. Fähndrich, M., aiken, M., Hawblitzel, C., Hodson, o., Hunt, G., larus, J.r., and levi, s. language support for fast and reliable message-based communication in singularity os. In Proceedings of the First ACM SIGOPS/EuroSys European Conference on Computer Systems (leuven, belgium, apr.). aCM Press, new york, 2006, 177–190.

7. Flatt, M. and Findler, r.b. Kill-safe synchronization abstractions. In Proceedings of the 2004 ACM SIGPLAN Conference on Programming Language Design and Implementation (Washington, d.C., June). aCM Press, new york, 2004, 47–58.

8. Hinchey, M., Jackson, M., Cousot, P., Cook, b., bowen, J.P., and Margaria, t. software engineering and formal methods. Commun. ACM 51, 9 (sept. 2008), 54–59.

9. Hunt, G. and larus, J. singularity: rethinking the software stack. ACM SIGOPS Operating Systems Review 41, 2 (apr. 2007), 37–49.

10. Hunt, G., aiken, M., Fähndrich, M., Hawblitzel, C., Hodson, o., larus, J., levi, s., steensgaard, b., tarditi, d., and Wobber, t. sealing os processes to improve dependability and safety. In Proceedings of the Second ACM SIGOPS/EuroSys European Conference on Computer Systems (lisbon, Portugal, Mar.). aCM Press, new york, 2007, 341–354.

11. orgovan, V. and tricker, M. An Introduction to Driver Quality. Microsoft WinHeC 2004 presentation ddt301, new orleans, la, 2003.

12. spear, M.F., roeder, t., levi, s., and Hunt, G. solving the starting problem: device drivers as self-describing artifacts. In Proceedings of the EuroSys 2006 Conference (leuven, belgium, apr.). aCM Press, new york, 2006, 45–58.

 

James Larus ( [e-mail]) is director of research and strategy in the extreme Computing Group at Microsoft research, redmond, Wa.

Galen hunt ( [e-mail]) is principal researcher in the Microsoft research operating systems Group and leads the Menlo project and the singularity project at Microsoft research, redmond, Wa.