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
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.
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
Source code for the Singularity system is available for noncommercial
use at http://www.codeplex.com/sin-gularity.
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.
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,
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,
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,
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 ( firstname.lastname@example.org) is director of
research and strategy in the extreme Computing Group
at Microsoft research, redmond, Wa.
Galen hunt ( email@example.com) is principal
researcher in the Microsoft research operating systems
Group and leads the Menlo project and the singularity
project at Microsoft research, redmond, Wa.