Henry M Levy's relevant 1984 book, Capability-Based Computer Systems, is available free in PDF form on the author's web site: http://homes.cs.washington.edu/~levy/capabook/
Single Address Space Operating System
41–50 of 53 posts
Re: Single Address Space Operating System
#42A 128bit address space would be fun. Of course as the page mentions, if you want to use IPv6 for this, you actually want something more like a 196bit address space or just round it up to a 256bit address space. Imagine all the world's computers running in a single unified address space. All network access is abstracted away, loading a resource is as simple as loading a memory address. It would be like a new golden er…
> All network access is abstracted away Which is a BAD thing, because it's one hell of a leaky abstraction. http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...
Working in embedded, I am used to assuming most of those working with just local resources.
> 1.The network is reliable.
I don't assume my file system is reliable. Flash fails.
> 2.Latency is zero.
Latency is non-0 even on local access! My team's requirements is that anything that may take more than ~1ms is done async. This includes memcopy!
> 3.Bandwidth is infinite.
Never has been, even locally.
> 4.The network is secure.
Local busses are not secure either.
> 5.Topology doesn't change.
I'll give'em that, although this is hopefully less of a problem now days, ignoring NATs...
> 6.There is one administrator.
Again, the industry has hopefully evolved to understand finer grained access controls.
> 7.Transport cost is zero.
Nope, never has been even locally. You doing something consumes resources from someone else.
> 8.The network is homogeneous.
Half the fun is in things being heterogeneous! Put work where it is best done at.
Re: Single Address Space Operating System
#43Earlier quoted context omitted.
In short, private virtual addressing is legacy cruft from a time when this was the only way to organize things due to a constrained memory block identifier namespace. Think about it like IPv4 vs. IPv6, i.e. hacks like NAT, vs. "everything has its own IP address in a single flat address space of IPs". It's the same, but with computer memory. And it has the same benefits.
I'm still not seeing the real benefits. What, specifically, is bad/wrong about the traditional way of doing process isolation, and what does this approach bring to the table ?
The folks at Microsoft Research who worked on Singularity claim the so called "Unsafe Code Tax" from the existing system is a 30-40% performance hit.
http://webcourse.cs.technion.ac.il/236376/Spring2013/ho/WCFi...
Re: Single Address Space Operating System
#44The Apple Newton did this; used a single address space and some fine-grain protection capabilities of the MMU to get proper security. It was . . . okay, but it's unclear what the performance hit would have been if we had run out of hardware-level protection IDs (there were 15 or 16 domains, IIRC). ARM later deprecated the MMU features that we used (and properly so, I think). There's a 1994 COMPCON paper on it.
Indeed, and here it is: http://waltersmith.us/newton/COMPCON-OS.pdf (I also updated the c2 wiki.)
The MMU features were available on ARMs for a surprisingly long time, and I remember seeing at least one embedded OS other than Newton that used them.
Re: Single Address Space Operating System
#45Earlier quoted context omitted.
In short, private virtual addressing is legacy cruft from a time when this was the only way to organize things due to a constrained memory block identifier namespace. Think about it like IPv4 vs. IPv6, i.e. hacks like NAT, vs. "everything has its own IP address in a single flat address space of IPs". It's the same, but with computer memory. And it has the same benefits.
That's true but I think the bigger reason is that a single address space makes system calls as cheap as regular function calls, since there is no kernel boundary any more. Ironically, VxWorks's latest major rev was all about turning memory protection on since overwhelmingly people prefer the performance hit of kernel calls over the heisenbugs that come from stomping on the kernel's code and data structures.
But, like you said, you still need protection of kernel data, which means that you need to execute kernel code on a stack not writeable by the user, at a greater permission level that allows ONLY the kernel code to modify kernel pages. Single-address-space or not I can't see these needs being met in a cheaper way than what we already have, presuming that kernel code/data are in never-invalidated global pages available in every address space.
Edit: Oh, I see from your other comment that you're talking about the benefits to people who don't feel this need.
Re: Single Address Space Operating System
#46Earlier quoted context omitted.
I'd argue that at this point one has to be aware of latency and concurrency on the local system also, and any programming model ignores this at their peril. It's the greatness of the potential of failure/hang on all actions that separates local RAM access from distributed computing. You don't generally need to worry about your app hanging indefinitely because of a memory read.
While true, there's enough orders of magnitude in play that the same mechanisms can only rarely be optimal for both. Reaching into a chunk of NUMA space you don't own vs. reaching out to a highly-contended hard drive on the other side of the world are forever likely to be too different to unify.
Compare order of magnitude for register access versus cache versus RAM versus HDD.
With page files, all of those are treated the same by the programmer.
Local HDD can already have access latency similar to the local network!
It is another order of magnitude to go beyond that. Meh.
Reliability is, IMHO, the bigger issue.
Re: Single Address Space Operating System
#47I've just been learning about OSv from Cloudius Systems. More than just a single address space they have a single process (intended to run as a KVM guest). It makes some interesting optimizations possible and they get some incredible results: memcached, unmodified, runs faster in their KVM guest than it does on the bare metal. It seems limiting at first, but for the right use case their approach is really worth a look.
Re: Single Address Space Operating System
#48Could this be retrofitted onto any mainstream OS? I guess the answer is "no" for Unix, because of fork(). But how about Windows?
The mill CPU [1] has a single address space and they plan to port linux to it.
Re: Single Address Space Operating System
#49Microsoft's Singularity http://en.wikipedia.org/wiki/Singularity_(operating_system) project was able to eschew the MMU and use verification to prove that programs couldn't harm the kernel or each other. Structuring a kernel like this makes the micro-kernel idea much more palatable as context switch overheads drop dramatically.
Here's a crazy idea: single addresss space for the kernel, virtual memory for applications in userland since their memory grows more unpredictably. I guess this dual approach would need hardware support?
Re: Single Address Space Operating System
#50Surprised no one has mentioned that the Lisp Machine operating system worked this way. Maybe it doesn't count because there was no protection against intentional reading or writing of memory belonging to other apps or the OS. But the protections against unintentional writing were good enough to make for a remarkably robust system, in a time when nobody cared about security.
For anyone interested, the Lisp Machine OS was called Genera:
http://en.wikipedia.org/wiki/Genera_%28operating_system%29
Fascinating thing.