It's a radical idea, on the same level of jumping from monolithic kernel to micro kernel system.
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.
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).
Interesting ideas though I don't know enough about kernel and language design to know if there are any revolutionary ideas in this or just an evolution upon current thinking.
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.
As I started reading the first paragraphs the thing that kept popping in my mind was Java. It almost seemed like they were describing java. Specially the part about garbage collection, although they did not named it garbage collection. They simply described that resources would be released once nobody was using them.
The point is sort of that they're taking ideas from languages like Java and actually using them for OS/system code. You're right, it's all old hat for programming languages, but using it for the OS itself (usually done in C or assembler) is quite unusual.
Exactly. Dig deep enough in any modern OS and you'll find a heritage that dates back to the 60s. Since then we've come a long way. Byte-code VMs, advanced garbage collection, rich and robust interoperability between modules and services (JARs, .NET assemblies, WSDL, etc, etc.) But all of this is layered on top of the OS, which still has very primitive foundations.
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.
Java popularized the idea of a VM but it wasn't the first language to do so, nor the last. Today that idea has spread much farther. The JVM is a general purpose platform (Scala, Clojure, JRuby, etc.) And the .NET Common Language Runtime has taken many of the same ideas and run with them (indeed, that's where a lot of the technical underpinnings for the Singularity project come from). Not to mention LLVM and many other projects.
There's a really nice microkernel OS out there that you can play around with, it's called QnX, unfortunately it's not open source. QnX is huge in the embedded world, but it also runs on x86.
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.