
Programming languages and the Singularity OS - spooneybarger
http://cacm.acm.org/magazines/2010/8/96608-the-singularity-system/fulltext
======
ww520
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.

------
Qz
_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)._

I'm on board with that.

------
hartror
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?

~~~
tbrownaw
Not a Phd, but I'll take a stab at it anyway...

 _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...](http://research.microsoft.com/apps/pubs/default.aspx?id=52716)
)

In sounds like it's an object-capability system, which is very cool.

------
fmora
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.

~~~
powrtoch
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.

So it's at least an interesting experiment.

~~~
InclinedPlane
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.

------
jacquesm
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.

