Effects of the Single Address Space Paradigm on

Effects of the Single Address Space Paradigm on CPU and OS Design for a Distributed Computer System Donald S. Miller ASU 64 -bit OS Group 10/2/2020 1

What’s a Paradigm? u u Constellation of beliefs, values, techniques and so on shared by the members of a given community that implicitly define the legitimate problems and methods of a research field for succeeding generations of practitioners 1 v attracts an enduring group of adherents away from competing modes of scientific activity v sufficiently open-ended to leave all sorts of problems for the group of practitioners to resolve Includes law theory, application and instrumentation together Examples: Aristotle’s physics, Ptolemaic astronomy, Galileo’s motion studies, Copernican astronomy, Newtonian mechanics, Einstein's relativity and Process-Oriented OSs and Single Address Space Operating Systems __________ 1. The Structure of Scientific Revolutions, 3 rd Edition, Thomas S. Kuhn, University of Chicago Press, 1996. ASU 64 -bit OS Group 10/2/2020 2

Process-Oriented Paradigm u u u u ASU 64 -bit OS Group Each process runs in it’s own virtual address space v virtual addresses are (process) context dependent Process boundaries encapsulate and bind temporary virtual address spaces, execution state, objects, protection domains and principals Persistent storage is in a separate namespace - the file system Message-based communication or RPC on top of message passing is the most prevalent mechanism for data exchange and synchronization between executing entities Page-based object granularity Threads encapsulated within a process - domain crossing and machine migration without an address space and thread context switch essentially impossible Layered system structure - operating system kernel and services and userlevel servers and programs layered on top of each other 10/2/2020 3

Process-Oriented Paradigm (continued) u u u u ASU 64 -bit OS Group Obtaining operating system services requires a domain crossing AND entry into privileged supervisor mode Process and data migration difficult - involves creating a new namespace for data (DSM) and dealing with distinct machine namespaces for code Difficult to directly support OOD and OOP - preprocessors and OS runtime systems are needed OS support for protection implementation protection policy are intertwined Access authorization, resource accounting and name services typically require kernel services or intervention Copy set management is usually page-based and requires broadcasts reducing scalability Network-wide fault tolerance requires additional mechanisms 10/2/2020 4

Process-Oriented Paradigm (concluded) u ASU 64 -bit OS Group Examples of Process-Oriented operating systems v Industrial u MULTICS, UNIX, MVS, Mach, Chorus, VMS, NT v Research u Exokernel, L 4, SPIN 10/2/2020 5

Single Address Space Paradigm u All programs run in a single virtual address space that covers all levels of the memory hierarchy, all nodes of a network and persists for the life of the computer system. This leads to the following 5 properties. 1. Permanent and unique binding of all data and code to virtual addresses. 2. The ability to freely reassociate memory objects, access rights, protection domains, virtual addresses, principals and threads. 3. A single network-wide namespace backed by the local demand paged memory management on every node and that includes all levels of the memory cache hierarchy. 4. Object, thread and protection domain mobility across the entire networkwide virtual address namespace. 5. Separation of ownership of code and ownership of execution of a computation. ASU 64 -bit OS Group 10/2/2020 6

Single Address Space Paradigm (continued) u u u u ASU 64 -bit OS Group All programs run in the same virtual address space v virtual addresses are not context dependent Execution state, objects, protection domains and principals are not bound to virtual addresses and hence not bound to each other Persistent storage is in the same virtual address namespace Shared memory is the most prevalent mechanism for data exchange and synchronization Object granularity can be independent of page granularity Threads can travel throughout the virtual address space without an address space switch or a thread context switch System architecture can be flat and modular - operating system services, environment servers and user-level programs can be made accessible to each other and themselves via simple procedure calls and returns 10/2/2020 7

Single Address Space Paradigm (continued) u u u ASU 64 -bit OS Group Obtaining operating system services is orthogonal to entry into privileged supervisor mode Process and Data Migration is straight-forward - objects and threads exist at the same virtual addresses on all nodes; kernel structures can be replicated or represented by surrogates on different nodes OOD and OOP can be directly supported - a protection domain can translate directly into an instantiation of an object class available at the user level - preprocessors and OS run-time systems are not needed; base classes can be extended via overrides at the user level Clean separation of OS support for protection implementation and userlevel definition of protection policy is simple Access authorization, resource accounting and name services can be done at the user level The common virtual address space provides simple scaleable per object copy set management and a lowest level cache for fault tolerance 10/2/2020 8

Single Address Space Paradigm (concluded) u ASU 64 -bit OS Group Examples of Single Address Space Operating Systems v Without additional protection hardware assistance u Opal, Mungi, Arius, Carthage (KFRPC) v With additional protection hardware assistance u AS/400, MONADS, To. M, Carthage (FRPC), Sombrero 10/2/2020 9

Sombrero Principals ASU 64 -bit OS Group 10/2/2020 10

SYSTEM ARCHITECTURE Process Oriented OS u ASU 64 -bit OS Group Layered system structure - operating system kernel and services and userlevel servers and programs layered on top of each other 10/2/2020 Single Address Space OS u System architecture can be flat and modular - operating system services, environment servers and user-level programs can be made accessible to each other and themselves via simple procedure calls and returns 11

SYSTEM ARCHITECTURE Process Oriented OS u ASU 64 -bit OS Group Obtaining operating system services requires a domain crossing AND entry into privileged supervisor mode 10/2/2020 Single Address Space OS u Obtaining operating system services is orthogonal to entry into privileged supervisor mode 12

ASU 64 -bit OS Group 10/2/2020 13

SYSTEM ARCHITECTURE Process Oriented OS u ASU 64 -bit OS Group Difficult to directly support OOD and OOP - preprocessors and OS run -time systems are needed 10/2/2020 Single Address Space OS u OOD and OOP can be directly supported - a protection domain can translate directly into an instantiation of an object class available at the user level - preprocessors and OS run-time systems are not needed; base classes can be extended via overrides at the user level 14

SYSTEM ARCHITECTURE Process Oriented OS u ASU 64 -bit OS Group OS support for protection implementation protection policy are intertwined 10/2/2020 Single Address Space OS u Clean separation of OS support for protection implementation and user-level definition of protection policy is simple 15

SYSTEM ARCHITECTURE Process Oriented OS u ASU 64 -bit OS Group Access authorization, resource accounting and name services typically require kernel services or intervention 10/2/2020 Single Address Space OS u Access authorization, resource accounting and name services can be done at the user level 16