ASU 64-bit OS Group7/15/ Effects of the Single Address Space Paradigm on CPU and OS Design for a Distributed Computer System Donald S. Miller

ASU 64-bit OS Group7/15/ What’s a Paradigm? 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 u Includes law theory, application and instrumentation together u Examples: Aristotle’s physics, Ptolemaic astronomy, Galileo’s motion studies, Copernican astronomy, Newtonian mechanics, Einstein's relativity and u Process-Oriented OSs and Single Address Space Operating Systems ____________________ 1. The Structure of Scientific Revolutions, 3rd Edition, Thomas S. Kuhn, University of Chicago Press, 1996.

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

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

ASU 64-bit OS Group7/15/ Process-Oriented Paradigm (concluded) u Examples of Process-Oriented operating systems v Industrial u MULTICS, UNIX, MVS, Mach, Chorus, VMS, NT v Research u Exokernel, L4, SPIN

ASU 64-bit OS Group7/15/ 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 network- wide virtual address namespace. 5.Separation of ownership of code and ownership of execution of a computation.

ASU 64-bit OS Group7/15/ Single Address Space Paradigm (continued) u All programs run in the same virtual address space v virtual addresses are not context dependent u Execution state, objects, protection domains and principals are not bound to virtual addresses and hence not bound to each other u Persistent storage is in the same virtual address namespace u Shared memory is the most prevalent mechanism for data exchange and synchronization u Object granularity can be independent of page granularity u Threads can travel throughout the virtual address space without an address space switch or a thread context switch 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

ASU 64-bit OS Group7/15/ Single Address Space Paradigm (continued) u Obtaining operating system services is orthogonal to entry into privileged supervisor mode u 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 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 u Clean separation of OS support for protection implementation and user-level definition of protection policy is simple u Access authorization, resource accounting and name services can be done at the user level u The common virtual address space provides simple scaleable per object copy set management and a lowest level cache for fault tolerance

ASU 64-bit OS Group7/15/ Single Address Space Paradigm (concluded) u 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, ToM, Carthage (FRPC), Sombrero

ASU 64-bit OS Group7/15/ Sombrero Principals

ASU 64-bit OS Group7/15/ SYSTEM ARCHITECTURE Process Oriented OS Single Address Space OS u Layered system structure - operating system kernel and services and user-level servers and programs layered on top of each other 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

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

ASU 64-bit OS Group7/15/201513

ASU 64-bit OS Group7/15/ SYSTEM ARCHITECTURE Process Oriented OS Single Address Space OS u Difficult to directly support OOD and OOP - preprocessors and OS run-time systems are needed 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

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

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