3 ms·

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 cur

by hartror 16y ago

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 16y ago
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=52716 http://research.microsoft.com/apps/pubs/default.aspx?id=5271... ) In sounds like it's an object-capability system, which is very cool.

by hartror 16y ago

tbrownaw 16y ago

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=52716 http://research.microsoft.com/apps/pubs/default.aspx?id=5271... ) In sounds like it's an object-capability system, which is very cool.