Live data from Hacker News

Single Address Space Operating System

c2.com

21–30 of 53 posts

Re: Single Address Space Operating System

#21
post #13

Earlier quoted context omitted.

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. The standard rebuttal to this thinking is Waldo et al. "A Note on Distributed Computing" from 1994. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7... "We argue that objects that interact in a distributed system need to be dealt w…

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.

Re: Single Address Space Operating System

#22
post #11

A 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…

"It would be like a new golden era for C!"

Well, it'd certainly be a new golden era for DRAM manufacturers as every pointer in the system bloats up to 8x original size just to support a 0.1% use case...

Re: Single Address Space Operating System

#23
post #6
post #4

Earlier quoted context omitted.

Do you have any insight for what the security implications would be (if any) for an OS like this?

Security is pretty solid in terms of things like libraries where every library entry point is a call to a particular address. That eliminates a number of dynamic linking vulnerabilities. Every process can have its own memory prefix (rather than everybody thinking they are at 0) which gives better visibility to memory incursion and excursions. Kernel space is distinct address from non-kernel space etc (this got really…

Every process can have its own memory prefix (rather than everybody thinking they are at 0)

The way you describe this, it sounds like segmentation. Wouldn't the value of each processing having a memory prefix be that all its internal data would think they have an offset of zero?

Re: Single Address Space Operating System

#25
post #24

I was disappointed that there was no real discussion of why you would want to do this. I see some potential for interesting optimizations, but that's ... it.

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.

Re: Single Address Space Operating System

#26

As shown in the article the system i from IBM (aka AS/400) is an example of this architecture. Originally 48bit it moved to 64bit when the RISC (power) processors came to the forefront. Yet that memory model is only element to the longevity and flexibility of the platform. However their best trick was keeping the machine code and OS so separate than when migrating to RISC from CISC you didn't even need the source cod…

The apps and most of the OS are distributed as the equivalent of high level byte code using 128 bit pointers. Once run it gets translated into the local machine code.

For anyone unfamiliar with the AS/400 and predecessors I highly recommend the expensive book by Frank Soltis who is largely the architect of it. Many things were done very differently than other operating systems and applications. http://www.amazon.com/Inside-AS-400-Second-Edition/dp/188241...

Re: Single Address Space Operating System

#28
Microsoft'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.

Re: Single Address Space Operating System

#29
post #24

I was disappointed that there was no real discussion of why you would want to do this. I see some potential for interesting optimizations, but that's ... it.

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.

Re: Single Address Space Operating System

#30
post #6

Earlier quoted context omitted.

Security is pretty solid in terms of things like libraries where every library entry point is a call to a particular address. That eliminates a number of dynamic linking vulnerabilities. Every process can have its own memory prefix (rather than everybody thinking they are at 0) which gives better visibility to memory incursion and excursions. Kernel space is distinct address from non-kernel space etc (this got really…

Every process can have its own memory prefix (rather than everybody thinking they are at 0) The way you describe this, it sounds like segmentation. Wouldn't the value of each processing having a memory prefix be that all its internal data would think they have an offset of zero?

I was thinking more along the lines of being able to do binary arithmetic on pointers for validation,

   ptr & prefixmask != prefix
means its out of range. That is a pretty cheap optimization, VMS and SunOS both used that sort of check in kernel space to insure that the kernel wasn't about to dereference a pointer outside of kernel space (potentially in some random process).
Post reply on HN