Sharing and Protection in a Single Address Space Operating System

Notes by Paul Coleman, Feb 18 1998, updated by Thorsten von Eicken Jan 28, 1999

Opal aims to exploit wide-address architectures "to integrate and to improve the reliability and performance of complex, cooperating applications manipulating large persistent data structures." The paper claims that sharing is simplified because addresses are context-independent, resolving to the same data regardless of who uses them. To protect the data Opal uses protection domains. The executions units, threads, can name all of the data in the system, but the threads access will be limited by the rights in the protection domain. This is an unusual separation of addressing and protection.

Private address Spaces

Pros:

• Increased amount of address space available to all programs.
• Hard memory protection boundaries.
• Easy cleanup on program exit.

Cons:

• Obstacles to efficient cooperation between protected application components: Pointers have no meaning outside of the process that created them. This causes difficulty in pointer-based memory sharing..
• Pointer problems force different processes to copy large amounts of data when they wish to share with another process.

Opal shared address spaces

• memory is divided into segment
• threads are the unix of execution
• protection domains define the context in which threads execute in: a protection domain specifies which segments a group of threads has access to
• capabilities are implemented using 256-bit password capabilities
• threads (groups?) can attach/detach segments
• IPC is done through portals. portals are referenced through capabilities and specify a 64-bit entry point

Discussion questions?

• The re-use of address spaces may lead to fragmentation, and a loss of contiguous address space. Is this acceptable?
• Opal does not support fork, copy-on-write, and generally makes is diffult to have private per-thread data
• Are the applications mentioned in the paper typical of anything other than CAD?
• Opal provides the functionality to share and protect data effectively, but how does one actually write a program to utilize this? The concept of "a program" has be drastically changed, is there a paradigm shift needed for developers to fully utilize Opal's strengths?
• Do persistent segments really imply that files aren't needed?
• Performance, is there any implication?