Single address space operating system
In computer science, a single address space operating system (or SASOS) is an operating system that provides only one globally shared address space for all processes. In a single address space operating system, numerically identical (virtual memory) logical addresses in different processes all refer to exactly the same byte of data.[1]
In a traditional OS with private per-process address space, memory protection is based on address space boundaries ("address space isolation"). Single address-space operating systems make translation and protection orthogonal, which in no way weakens protection.[2][3] The core advantage is that pointers (i.e. memory references) have global validity, meaning their meaning is independent of the process using it. This allows sharing pointer-connected data structures across processes, and making them persistent, i.e. storing them on backup store.
Some processor architectures have direct support for protection independent of translation. On such architectures, a SASOS may be able to perform context switches faster than a traditional OS. Such architectures include Itanium, and Version 5 of the Arm architecture, as well as capability architectures such as CHERI.
A SASOS should not be confused with a flat memory model, which provides no address translation and generally no memory protection. In contrast, a SASOS makes protection orthogonal to translation: it may be possible to name a data item (i.e. know its virtual address) while not being able to access it.
SASOS projects using hardware-based protection include the following:
- Angel
- IBM i (formerly called OS/400)
- Iguana at NICTA, Australia
- Mungi at NICTA, Australia
- Nemesis
- Opal
- Scout
- Sombrero
Related are OSes that provide protection through language-level type safety
- Br1X
- Genera
- JX a research Java OS[4]
- Phantom OS
- Singularity
- Theseus OS[5]
- Torsion[6]
See also
References
- ↑ Eric J. Koldinger; Jeffrey S. Chase; Susan J. Eggers (September 1992). "Architecture support for single address space operating systems". ACM SIGPLAN Notices 27 (9): 175–186. doi:10.1145/143371.143508.
- ↑ "Single Address Space Operating Systems". 13 November 1995. Section 2: "Memory Protection". https://cgi.cse.unsw.edu.au/~reports/papers/9504.pdf.
- ↑ Jeffrey S. Chase; Henry M. Levy; Michael J. Feeley; Edward D. Lazowska (November 1994). "Sharing and protection in a single-address-space operating system". ACM Transactions on Computer Systems 12 (4): 271–307. doi:10.1145/195792.195795. https://homes.cs.washington.edu/~levy/opal/opal-tocs.pdf.
- ↑ "The JX Operating System". http://www4.cs.fau.de/Projects/JX/publications/jx-usenix.pdf.
- ↑ Kevin Boos, Namitha Liyanage, Ramla Ijaz, and Lin Zhong. "Theseus: an Experiment in Operating System Structure and State Management". 2020.
- ↑ "Torsion Operating System". quote: "Torsion ... a single address space multitasking operating system with transparent data persistence."
Bibliography
- Jeffrey S. Chase; Henry M. Levy; Michael J. Feeley; Edward D. Lazowska (November 1994). "Sharing and protection in a single-address-space operating system". ACM Transactions on Computer Systems 12 (4): 271–307. doi:10.1145/195792.195795..
- Heiser, Gernot; Elphinstone, Kevin; Vochteloo, Jerry; Russell, Stephen; Liedtke, Jochen (1998). "The Mungi Single-Address-Space Operating System". Software: Practice and Experience 28 (9): 901–928. doi:10.1002/(SICI)1097-024X(19980725)28:9<901::AID-SPE181>3.0.CO;2-7. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.146.4216&rep=rep1&type=pdf.
- Michael M. Swift; Brian N. Bershad; Henry M. Levy (December 2003). "Improving the reliability of commodity operating systems". ACM SIGOPS Operating Systems Review 37 (5): 207. doi:10.1145/1165389.945466.
- Eric J. Koldinger; Jeffrey S. Chase; Susan J. Eggers (September 1992). "Architecture support for single address space operating systems". ACM SIGPLAN Notices 27 (9): 175–186. doi:10.1145/143371.143508.
 |  |
