Single Address Spaces and Single Address Space Operating Systems

1
Single Address Spaces and Single Address Space
Operating Systems

• Donald S. Miller
• Computer Science and Engineering Department
• Arizona State University

2
OUTLINE

• Introduction to Single Address Space Operating
  Systems
• What is a Single Address Space?
• What is a Single Address Space Operating System
  (SASOS)?
• Characteristics of a Single Address Space
• Advantages that can be provided by a SASOS
• Why build a SASOS now?
• Essence of the Single Address Space Paradigm
• SASOSs vs. Process-Oriented OSs - a more detailed
  look
• SASOSs with and without Additional Hardware
  Support
• Motivation for Hardware Support for a SASOS
• SASOS Applications
• Current Technology Trends that Favor a
  HW-Supported SASOS
• SASOS Disadvantages
• Summary

3
Process-Oriented Operating Systems(Multiple
Address Space Operating Systems) andSingle
Address Space Operating Systems(SASOSs)

• Process-Oriented operating systems
• Multiple virtual address namespaces
• Unix , NT , MVS
• Single address space operating systems
• Single VA namespace
• Opal, Mungi, Grasshopper, Monads, AS/400,
  Sombrero
• SASOSs feasible nowadays because of 64-bit CPUs
• Paradigm is different

4
Why Single Address Space Operating Systems?

• Recent 64-bit Microprocessors have made an 18.4
  Quintillion Byte Address Space Potentially
  Available
• Current Process-Oriented Operating Systems and
  Processor Page-based Protection HW are Designed
  to Conserve Virtual Addresses by Reusing them
• These Facts have led to Investigations of
  Alternative Operating System and Processor
  Architecture Models
• One such Model is to establish a Single Address
  Space in which all code and data reside and then
  Design an Operating System Specifically to run in
  this Environment
• These Single Address Space OSs are called SASOSs

5
Characteristics of a Single Address Space

• Virtual Addresses can be permanently and uniquely
  bound to all code and data objects
• VAs can serve as unique names
• VA space can serve as the only namespace
• The Virtual Address namespace spans all levels of
  the storage hierarchy on every node
• All Physical storage can be viewed as a hierarchy
  of caches for the contents of virtual addresses
• The Virtual Address namespace is manipulated
  directly by the CPU and access to it is
  controlled directly by memory and protection
  management hardware
• the CPU can directly enforce principal protection
  and resource allocation access policies on all
  objects defined in the system as it manipulates
  virtual addresses

6
Advantages that can be Provided by a SASOS

• Address translations remain the same for all
  programs
• Threads are free to travel throughout the VA
  space with no changes in the environment in which
  they are running in except for protection context
• Network-wide communication requires no prior or
  additional setup
• Internal pointers and pointers into other objects
  remain the same across all levels of storage and
  all programs
• marshalling, flattening and dynamic linking not
  needed
• Persistence without use of a separate file system
• Protection by restricting what a computation is
  allowed to access rather than what it is allowed
  to address
• managing IPC is reduced to managing protection

7
Advantages that can be Provided by a
SASOS(continued)

• SASOSs increase the available choices
• for structuring applications
• for structuring the operating system
• for sharing, protecting and storing data
• for communication between programs
• Fundamental Issue - how to structure an OS to
  provide
• a simple program development environment
• high performance
• in a system where conserving address space is no
  longer a driving concern

8
Why build a SASOS now?

• Whats changed?
• Whats the reason for building a SASOS?
• Why arent people building them?

9
Whats Changed?

• 64-bit RISC processors are available.
• ? a paradigm shift to single address space
  operation is possible
• Modern software has become increasingly large and
  complex
• ? increased SW engineering efforts are needed to
  reduce the costs of program development
• Performance increases from reducing chip feature
  sizes will begin to decline in about 10 years
• ? Increased performance will have to come from
  architectural changes

10
Whats the reason for building a SASOS?

• Reducing the costs of program development
• simpler mechanisms to support sharing and
  communication between programs
• common naming mechanisms
• system level support for OOD and OOP
• Higher performance
• gains from architectural changes
• Increased support for distributed applications
• Object-oriented DDBMS systems
• CAD/CAM systems
• Distributed parallel computations
• Better match to needs of real-time applications

11
Why arent people building them?

• Going from multiple to single address spaces is a
  paradigm shift -there are costs associated with
  the following in a single address space
• Understanding the paradigm shift
• Learning programming differences
• Mastering new approaches to HW/SW design
• The CPU protection hardware necessary to make a
  SASOS viable introduces incompatible hardware
• new software may not run on the old hardware
• old software will not be able to take advantage
  of new HW
• ? consequent initial economic disadvantages.

12
The Multiple to Single Address Space Paradigm
Shift

• PARADIGM ? 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
  practitioners1
• Shifting from multiple address spaces to a single
  address space constitutes a paradigm shift
• brought about because in a single address space
  the set of virtual addresses can be used as a
  system-wide namespace
• So - Whats a namespace?

____________________ 1. The Structure of
Scientific Revolutions, 3rd Edition, Thomas S.
Kuhn, University of Chicago Press, 1996.
13
Names, Namespaces and Single Address Spaces

• A name is a string that identifies an object.
• A binding is a mapping between a name and an
  object.
• A namespace is a set of bindings of names to
  objects. Alternatively, its a domain of possible
  names.
• Namespaces include file names, IP numbers, port
  numbers and addresses in a virtual address space.

A single address space is one namespace that
consists of the entire range of virtual
addresses. Each virtual address is unique and is
permanently bound to a byte of a data object.
14
Essence of the Multiple to Single Address Space
Paradigm Shift
Going from multiple namespaces in which object
names can vary and are determined by the logical
structures they are associated with, e.g.,
process, file or record, or by the physical
container that holds them, e.g., cache, RAM or
disk Going to a single network-wide namespace in
which object names are invariant and are
determined by the unique virtual addresses used
to access them

Since VAs are directly operated upon by CPUs, the
focus shifts from naming objects by the changing
logical or physical structures associated with
them to using VAs as the primary
identifying/locating /accessing mechanism for all
objects wherever they are and whenever they are
used.

15
Single Address Space vs.Multiple Address
SpaceParadigms

• Two sets of distinguishing characteristics
• Features that differentiate between all SASOSs
  and process-oriented operating systems
• Additional features that differentiate between
  HW-supported SASOSs and SASOSs built on stock
  RISC processors

16
Single Address Space vs.Multiple Address
SpaceParadigms

• Process-Oriented OSs
• Each process runs in its own VA space on a
  single node - VAs are context dependent
• Process boundaries encapsulate and bind
  temporary VA spaces, execution state, objects,
  protection domains and principals
• Persistent storage is in a separate namespace -
  the file system
• Threads encapsulated within a process - domain
  crossing and machine migration without an address
  space or thread context switch essentially
  impossible

• SASOSs
• All programs run in the same VA namespace which
  spans all nodes - VAs are not context dependent
• Execution state, objects, protection domains and
  principals are not bound to VAs and hence not
  bound to each other
• Persistent storage is also in the same virtual
  address namespace
• Threads can travel throughout the virtual address
  space without an address space switch or a thread
  context switch

Program VA Space
Binding of Major Abstractions
Persistent Storage
Thread Mobility
3/27/2016 60618 AM
ASU 64-bit OS Group
16
17
Single Address Space vs.Multiple Address Space
Paradigms(continued)
Process-Oriented OSs
SASOSs

• Shared memory is the most prevalent mechanism for
  data exchange and synchronization
• No prior or additional setup necessary for
  programs to communicate using shared memory
• Servers can be active or passive
• Task and data migration is straight-forward -
  objects and threads exist at the same virtual
  addresses on all nodes

• Message-based communication or RPC on top of
  message passing is frequently required for data
  exchange and synchronization
• IPC using shared memory requires prior and
  additional setup and mapping
• Servers must be active
• Task and data migration is difficult - involves
  creating a new namespace for data (DSM) and
  dealing with distinct machine namespaces for code

Data Exchange and Synchronization
Shared Memory
Server Options
Task and Data Migration
3/27/2016 60618 AM
ASU 64-bit OS Group
17
18
Software SASOSs vs. Hardware Supported SASOSs

• Software
• Use stock 64-bit RISC processors
• Require additional software communication
  protocols for protection
• Examples Opal, Mungi, Grasshopper
• Hardware supported
• Require additional CPU hardware for protection
• Examples AS/400, Monads, Sombrero
• A HW-supported SASOS can take fuller advantage of
  single address space characteristics.

19
DESIRED PROTECTION HARDWARE FUNCTIONALITY

• Separation of Address Translation and Address
  Protection Functions
• Hardware Caching of Allowed Protection Domain
  Crossings
• Protection Domains for Threads Distinct from the
  General Protection Context
• Implicit Domain Crossing using Ordinary
  Instructions
• Protection for Variable Granularity Object Sizes

20
SASOSs on Stock Processorsvs.SASOSs with
Additional CPU Protection Hardware

• SW SASOSs
• Obtaining system services requires a domain
  crossing AND entry into privileged supervisor
  mode
• Layered system structure - operating system
  kernel, executive services and user-level servers
  layered on top of each other
• Direct support for OOD and OOP is difficult -
  preprocessors and run-time systems are needed

• HW-Supported SASOSs
• Obtaining operating system services is orthogonal
  to entry into privileged supervisor mode
• System architecture can be flat and modular - OS
  services, environment servers and user-level
  programs accessible to each other via ordinary
  procedure calls
• OOD and OOP can be directly supported - an object
  class can be implemented directly as a
  protection domain and a server as an
  instantiation of the class base classes can be
  extended via user-level overrides

System Services
Operating System Structure
OOD and OOP Support
ASU 64-bit OS Group
3/27/2016 60618 AM
20
21
SASOSs on Stock Processorsvs.SASOSs with
Additional CPU Protection Hardware (continued)

• SW SASOSs
• Copy set replication and consistency management
  is usually page based and requires broadcasts
  reducing scalability
• Network-wide fault tolerance can require
  additional mechanisms
• Page-based object granularity
• Access authorization, resource accounting and
  name services typically require kernel services
  or intervention
• OS support for protection policy and protection
  implementation are intertwined

• HW-Supported SASOSs
• The common VA space enables simple scaleable
  per-object copy set replication and consistency
  management
• Naturally provides a lowest level cache for fault
  tolerance
• Object granularity can be independent of page
  granularity
• Access authorization, resource accounting and
  name services can be done at user level
• Clean separation of OS support for protection
  implementation and user-level definition of
  protection policy is simple

Replication Management
Fault Tolerance
Object Granularity
Privilege Level for Basic Services
Protection Policy and Implementation
3/27/2016 60618 AM
ASU 64-bit OS Group
21
22
Motivation for HW support for a SASOS

• Additional CPU-resident protection HW is
  essential to obtain
• A considerably improved program development
  environment
• Much greater performance
• Better support for distributed applications
• Because it makes fuller use of the properties of
  a single address space to provide protection,
  resource access and control transfer.

23
Protection, Resource Access and Control Transfer
HW-Supported SASOSs vs. SASOSs Built on Stock
RISC Processors(Sombrero, AS/400 and Monads vs.
Opal and Mungi)

• Centralized kernel-resident data structure for
  protection triples vs. capabilities
• Single inverted page table at the memory bus vs.
  multiple per-PD page tables
• Carrier protection domain vs. proxy/guard and
  PD-extension for domain crossings
• Direct support for object-oriented program
  development environment
• Implicit PD crossing at EVERY level

24
Differences between HW-Supported SASOSs
(Sombrero vs. AS/400 and Monads)

• Flat 64-bit address space - no segments
• No HW memory tagging or additional CPU
  instructions for capability and tag mgmt
• Network-wide single address namespace
• Single CAM-based inverted page table
• Simple extensible executive
• Availability of all single address space property
  advantages to applications

25
SASOS Applications

• Object-oriented distributed database management
  systems
• Multiple database/multiple programming model
  applications, e.g., CAD/CAM
• Distributed parallel computations
• Real-time systems

26
Killer Ap

• To succeed a SASOS needs a Killer Application
• Must benefit from SASOS advantages
• common unique and permanent naming scheme
• communications support for numerous large program
  modules
• sharing and protection support for a huge
  distributed database
• It must be widely used and currently costly
• Most likely candidate Object-Oriented DDBMS

27
Current Technological Trends that Favor a
Hardware-Supported SASOS
Advantage
Trend

• Increasing costs and difficulties reducing CMOS
  chip feature sizes below 0.1 micron
• Increasing disparity between CPU cycle times and
  RAM access times and increasing chip real-estate
• Decreasing ratio of inter-node access time to
  disk access time plus large local memories

• Increased performance will have to come from
  architectural changes such as shifting to single
  address space operation
• Large on-chip virtual caches can enable higher
  performance, and replacing TLB with a single
  CAM-based inverted page table at the memory bus
• Accessing code and data from remote node has
  additional advantage of not needing to be remapped

28
Current Technological Trends that Favor a
Hardware-Supported SASOS (continued)
Advantage
Trend

• Huge and inexpensive local RAM memories - 128MB
  and above
• Huge and inexpensive local disks - ? 8 gigabytes
• Multicast-oriented networks, e.g., ATM

• Local caching of services leading to greater
  advantages from thread mobility using passive
  servers
• Local caching of persistent data leading to
  greater advantages from not having to flatten
  data between disk and core when files are
  replicated
• SASOS distributed copy set management and VA
  space distribution facilitated by multicasts

29
SASOS Disadvantages

• SASOSs built on stock 64-bit processors
• Programming and performance improvements
  insufficient to overcome design, development and
  software engineering costs associated with
  shifting to the new paradigm.
• HW-Supported SASOS
• To make the shift to the single address space
  paradigm worthwhile requires additional
  CPU-resident HW causing
• Backwards HW and SW incompatibilities
• Programming differences
• Mastering new approaches to HW/SW design

30
Summary

• Advantages of a HW-Supported SASOS
• Improved program development environment
• Higher performance
• Better support for distributed applications
• A better match to the needs of real-time systems

CPU-resident protection hardware and a SASOS that
runs on it can be implemented now. This
combination makes fuller use of the properties of
a very large address space than contemporary
process-oriented systems for both single node and
distributed systems.