Programming languages and the Singularity OS
cacm.acm.org
cacm.acm.org
The main idea is to use a safe language (Java/C#) to provide process isolation instead of relying on the OS imposing separate process address space.
Safe language codes can be proved that they do no harm, cannot corrupt another program (the bytecode verifier will stop it). For the unsafe language programs (C/ASM), the current way to prevent them from stepping on each other is by putting them in separate address space processes with limited privilege (ring 3).
The main advantage with a safe language only system is that everything can be trusted enough that they can run in ring 0 in the kernel, thus very fast. There will be no more slow user mode to kernel mode system calls, no more ring 3 to ring 0 transition. It also allows all programs to run in one process address space, no more expensive process context switch (though thread context switch is still there). Inter-program messages will be very fast since they are in the same address space. Code quality will be improved with whole classes of bugs removed in safe languages.
Remember the complaint about microkernel? That most of its OS services are in user mode servers and thus incurring extra kernel-to-user mode transition? Imagine a system that has no kernel or user mode distinction and no mode transition.
The disadvantage of safe language system is that everything has to be in safe language, user program, kernel services, device drivers, etc, which is kind of impractical. Singularity allows "trusted" drivers written in unsafe languages. I don't know how well that works.
IMO a hybrid approach is more feasible. An OS with the traditional kernel (preferably microkernel) that supports unsafe language programs and drivers, and a safe-language kernel that allows verified safe-language programs and drivers to run in ring 0. This would maintain backward compatibility and allow radical new development that improve on quality and safety.
I'm on board with that.
Anyone with a CS PHD want to highlight some important points for the rest of us?
Unlike in other systems, processes in Singularity are software-isolated processes, or SIPs, that rely on language safety, not hardware mechanisms, to isolate system software components from one another. SIPs provide isolation and failure containment at far less performance cost than hardware mechanisms, so they can be used in more places than conventional processes.
This is the (IMO) really interesting part, and is why I've decided I like instead of dislike type-safe virtual machines on general principle.
The Singularity architecture avoids many of these problems. For example, SIPs are sealed processes that prohibit shared memory, in-process code generation, and dynamic code loading. A process that wishes to invoke an extension starts the extension code running in a separate SIP.
dlopen() cannot exist. I'm not sure how/if you could write your own JIT (say, for something like... a JVM?), you'd probably have to fully pre-compile down to MSIL. This is one of those "nice in theory" things that I suspect won't work so well in the real world, because the extra development overhead probably isn't worth the added safety in most circumstances.
Having this be a flag that a given process can declare in its manifest might be good, having an optional startup parameter to the OS to require it for all processes might also make sense. Making it universally mandatory seems questionable.
With only two exceptions, an ABI call affects only the state of its calling process. The two exceptions alter the state of a child process before or after it executes, but not during execution. The first is a call to create a child process, which specifies the code loaded for the child before it begins execution. The second is a call to stop a child process, which reclaims its resources after all threads cease execution. State isolation ensures that a Singularity process has sole control over its state. (From http://research.microsoft.com/apps/pubs/default.aspx?id=5271... )
In sounds like it's an object-capability system, which is very cool.
So it's at least an interesting experiment.
Shockingly, there's been very little research in operating system fundamentals. One of the most important OS breakthroughs in the past 20 years was little more than an open source re-implementation of POSIX UNIX (linux), but very little has been done in terms of honest to goodness green field OS development.
I suspect we're not quite "there" yet in terms of having all of the tools and techniques available to finally justify kicking over the old OS foundations and starting anew. I'm certain that byte-code VMs (perhaps even LLVM itself), high-level interop, and garbage collection will play a big role. I suspect that some of the hot new (or rejuvenated) trends in computing especially functional languages, immutable data based programming, noSQL data stores, and especially event-based systems will be key parts in the foundations of the next re-invention of operating systems.