CS 736 Reviews - Spring 2015

1. summary
This 1994 paper presents Opal, an operating system that provides a single 64-bit bit virtual address space rather than separate address spaces for each process. Additionally, the separation of addressing from protection is heavily emphasized in a paper that details how user processes (or more appropriately, threads) can share data in an efficient, yet protected manner.
2. Problem
In traditional OSs, each process has a private virtual address space. This makes cleanup and memory protection very simple, as each process is completely isolated. However, cooperation between processes is inefficient, as pointer-rich applications are forced to translate values between two unrelated address spaces. As a result, large systems of applications that share data end up with two distinct possibilities. The first is a set of independent processes that share data through some slow, complicated interprocess communication. Conversely, a single monolithic process is fast, but provides no protection between independent components. This paper attempts to achieve the benefits of both type of systems.
3. Contributions
The obvious contribution of the paper is treating all of the virtual address space as a single large, 64-bit space in which address bindings are handled by the system itself. This achieves fast performance, and simple shared memory between processes. A number of Opal specific “compiler steps” were developed in order to ensure proper addressing.
The main contribution is the separation of addressing and protection. The authors introduce the concept of capabilities and protection domains. These domains are an execution context for threads, and allow a thread to access a specific set of segments at a time. Seg can be attached and detached, allowing for flexibility in sharing code/data structures, while maintaining strict protection through access control lists.
A third, lesser contribution is the simple remote procedure calls through the use of portals. A thread will hold a capability containing a 64-bit portalID and this portalID indexes to a fixed location in the virtual address space, and allows the new domain to control exactly how it is accessed.
4. Evaluation
A detailed evaluation is provided through the context of a Boeing next generation CAD system. This CAD system uses a centralized relational database, and is very slow and will not scale well in the future. The authors present an interesting graph that shows that their “overlapping” system provides the same speed as a single monolithic kernel, but also provides protection. Several issues with the single address space are also presented (like forking), but possible solutions are offered.
5. Confusion
The authors mention password capabilities that are not maintained by the kernel. What exactly does this mean?
What exactly is the guard (as in the portal/guard system)?

Summary:

This article presents a single address-space operating system, Opal. In doing so, the authors explore how a single address-space system can be designed to handle faster data sharing without losing the protection offered by private address spaces. The authors also cover some of the issues inherent to single address spaces and related to creating these systems with resources designed for conventional address spaces.

Problem:

The authors wanted to re-evaluate operating systems with the introduction of 64-bit address space architectures. They argued that private address space systems sacrifice performance to achieve protection. They believe that removing the link between addressing and protection would make pointer based data sharing easier and that this could improve overall system performance.

Contributions:

Exploring single-address-space systems is one of the major contributions if this paper, irrespective of whether Opal was successful. This article was written at the advent of 64-bit architectures with the goal of putting this significant addition to the address space to better use by trying to deconstruct conventional processes and separating addressing and protection.

The designers of Opal built on existing operating system concepts to implement their system. They used the concept of segments and capabilities to create protection domains, the set of segments that a process could access. They introduced the concepts of portals to allow a process to switch domains, giving processes in their system the capability to share pointer based procedures.

Evaluation:

The authors implemented a working prototype of the Opal system on a Mach micro kernel. While not particularly ideal, they did a few comparison tests with a Unix system, also built on the same Mach platform. They compare performance using a producer-consumer application, implemented with a mediator to handle inter-tool dependencies. While Opal does seem to have comparable performance, the testing isn't exactly comprehensive since they only had a prototype at the time this article was written.

Confusion:

The article doesn't really talk about how they would go about testing the system from a protection point of view. Seeing as how the Opal design is such a big shift from traditional, private address space systems, I'm not entirely sure how the designers of Opal would go about proving that their system is just as safe as something like Unix.

1. Summary
The paper introduces Opal, a single-address-space operating system designed for 64-bit architecture. It presents memory sharing and protection in the operating system. The threads in the operating system share a single global virtual address space while ensuring protection of private data and code. The author contrasts this to the traditional model of private, virtual address spaces for each executing program.

2. Problem
The initial motivation behind Opal was the advent of 64-bit architecture and the radical increase in the amount of address space available to operating systems and applications because of that. The authors felt the need to rethink some of the fundamental operating system structure given this new architecture especially the address space of an operating system. Their proposal of a single global address space shared among all procedures and all data was to better organize the operating systems and its applications and also simplify sharing among applications that are inter-dependent and interact frequently thus avoiding some of the complexities involved in pointer address mapping and translation and improve performance. Another design goal seems to be the separation of addressing and protection of memory thereby increasing flexibility with which the application can share data and interact with each other.

3. Contributions
The main contribution of this paper was the use of a single address space with static addresses for all the programs in the OS. The paper discusses the pros and cons of this model with the traditional way of having private adress spaces for each process. The author. The authors state that advantages of having private address spaces like increasing the amount of memory available to each process, provide hard memory protection boundary and allow easy cleanup when a program exits can be achieved with single address space model. The traditional method does a poor tradeoffs between protection, performance, and integration and impede sharing in a class of applications in which there is a lot of interaction among its composed modules.
Another key idea of Opal was the separation of addressing and protection of memory. This was achieved using protection domains. The Opal units of execution, threads operate within a protection domain which restricts its access to a specific set of segments at a particular instant in time based on its capabilities.
In Opal, the primary form of sharing and communication between threads in different protection domains is via shared memory. Each domain has an entry point called the portal-ID. A thread knowing this ID can make a call to this domain via the portalID.
Another philosophy of Opal was the operating system must provide coarse-grained control over storage-allocation, protection and reclamation, while the fine-grained control is better provided at the language level by compilers and runtime systems.

4. Evaluation
The paper presents some experimental results using the Opal prototype for Boeing's aircraft CAD system. This experiment confirms that shared memory can significantly improve performance and scalability of integrated applications and demonstrates its use is compatible with sound software engineering principles. Execution time for three configurations: monolithic, decomposed and opal styled overlapping of a tree-indexing program built using mediators is presented. The overlapping organization, while as safe as the decomposed configuration is as fast as the monolithic configuration and this performance gain over the Unix-style decomposed configuration increases as the amount of shared data increases.
The paper also presents the performance of some specific Opal primitives like creating a new segment, performing an attach/detach of a segment, allocation of a domain. The performance of these primitives compares favorably with the performance of fork/exec/exit/wait of Unix

5. Confusion
Did this design inspire the "threads" in general? or was the term threads used in this paper because they share data?

1. summary
This paper presents the features and abstractions of Opal Operating System. Opal is a single global address space operating system build for integrated software environments on wide address architecture. This paper focuses on how sharing virtual address in a single global virtual address OS can be much efficient without compromising modularity or protection.
2. Problem
Private address space OS provide easier way of protection and isolation by restricting the virtual address to a process. This makes inter process communication and sharing memory very inefficient. Also pointers doesn't make sense outside their private address space. To address this issue, they propose a single global shared virtual address space between all the process.
3. Contributions
1) The key contribution of this paper is the novel idea of using the whole virtual address space as a global shared virtual space for all the process. This increases the efficiency for inter process communication and sharing memory. This also enables pointers to be used for sharing.
2) Protection is provided via the concept of protection domains(PD). PD define the rules and access rights for threads(units of execution). A thread can belong to one Process domain but multiple threads can be under a single PD (here the notion of protection and addressing is separated).
3) Portals are used for communication between different PDs. Portals define the access rights for the threads.
4) New type of loading and linking is required in this type of single address space OS. This is done with the original address rather than virtual address(as the virtual address are shared).
4. Evaluation
A prototype of the proposed Opal OS was implemented over MACH 3.0 microkernel. Various timings are provided for many basic operations like segment creation, cross-domain calls and domain management operations like fork,exit etc. These metrics show a substantial improvement over native MACH 3.0 microkernel. They also provide a comparison of various protection methods (monolithic, decomposed and overlapping) for tree index programs. The results show that overlapping configuration is as fast as monolithic but provides protection similar to that of decomposed configuration.
5. Confusion
Why is this idea not used in modern OS ?

1. summary
This article describes Opal, a single-address-space operating system and explores its memory sharing and protection support.

2. problem
Private address spaces isolates programs within private virtual address spaces and presents obstacles to efficient cooperation between protected application components. Pointer-based information is not easily shared, stored or transmitted. The cooperation is very expensive. And Opal's target applications are composed of interdependent components and rich interactions.

3. contributions
(1) Use single-address-space. Programs can directly share procedures and pointer-based data structures. The common address space allows dynamic imports and binding to data structures and code. It can bring benefits to the memory system implementation such as elimination of address overloading. Shared data should be accessed through procedural interfaces, and protection structures should be flexible enough to permit application-specific choice of how modularity is enforced. The structure can be extended to include network-wide data and persistent data.
(2) In the Opal, units of storage allocation and protection are segments, units of execution are threads. A protection domain is an execution context for threads. Domains are the subjects of memory access control. Given a segment capability, an executing thread can explicitly attach/detach that segment to its protection domain, permitting/forbidding threads executing within that domain to access the segment directly. An Opal domain can create one or more portals that permit other domains to call it in a protected and controlled manner. The basic storage management mechanism is reference counting, backed by bulk delete using resource groups.
(3) An Opal prototype is implemented on top of the March 3.0 microkernel. It supports basic system abstractions and coordinates the usage of address space. It also provides an application interface tailored to the c++ language. Code modules can be statically linked to global address space and can be shared and called dynamically.

4. evaluation
The author gives the Opal's application in Boeing’s aircraft CAD system, which is an example of a large integrated application with pointer-rich data structures. Besides, the author gives statistics for the time of creating a segment, allocating/calling/destroying a domain and making a cross-domain call. Deeper decomposition of the time is also given. However, there is no comparasion between the performance to that of private address space.

5. confusion
Does there exist mutual-reference so that there is a deadlock and some segments will never be deleted?

Summary
In this paper, "Sharing and Protection in a Single Address Space Operating System" the design and implementation of the Opal system is described. Opal is a single address space operating system and the authors put forward their results and design ideas on how the Opal system achieved sharing, without compromising on protection. Opal is designed for 64-bit architectures, and is implemented using a Mach 3.0 microkernel. Performance results for Opal on the CAD system is also discussed in detail supporting claims made in the rest of the paper.

Problem
The main goal of the Opal system was to explore how to leverage 64-bit architectures to develop a single-address space operating system which can achieve goals of sharing and protection without multiple address spaces. How do we separate sharing and protection into two different domains and achieve the goal of a flexible and performance rich OS ? Since 64-bit system can access large amounts of address space, do we need to redesign primary OS features to account for this change in architecture?

Contributions:
The main contributions of the paper are:
1. Memory in Opal, like other systems we considered, is divided and accessed into segments. The segments provide required flexibility in addressing.
2. Since the entire address space is a single address space, protection is provided using domains for a group of threads.
3. Thinking of addressing and protection as two different entities and distinguish between them.
4. Permissions can be granted by using segments, which can be given or removed dynamically.
5. Storage allocation and other resource management techniques are course grained, based on objects and resource groups.

Evaluation:
The Opal system is implemented using Mach 3.0 microkernel to discuss performance and support claims made in the paper. The Boeing CAD system application describes how the single address space mechanism implemented by the authors, benefits this application instead of going for a message passing approach which considerably affects performance. The authors also conclude that there are drawbacks and performance penalties involved in using a single-address space system. The paper is a little repetitive in terms of the different sections, but it is helpful since it gives justification for each of the design decisions made by the authors.

Confusion:
A discussion on how "password capabilities" are implemented and enforced would be great.

1. Summary
The article describes key features of Opal operating system, which has the design principle of a single address space for all applications in 64-bit wide architectures. Opal aims to restructure the system and improve integration between system and applications, by providing a global address space for all execution threads thus facilitating data sharing among them, but still providing necessary memory access protection. The paper also discusses about new abstractions needed to achieve its goal by building a prototype on Mach 3.0 microkernel.

2. Problem
Previous 32-bit machines, had limited address space resulting in reuse of addresses in applications. Though these systems provided modular execution environments with isolation, data sharing between them has proved inefficient and costly. In the present 64-bit machines, huge address space as an added benefit, the paper has tried to address the above problem and has evaluated the OS structure (Opal) by striking a good balance between performance, protection and integration.

3. Contributions
Opal design’s key feature is the separation of addressing and protection. A global single address space provides sufficient addresses in 64-bit machines with no loss of protection and convenient shared memory interaction, allowing flexibility in the system. Segments as collection of contiguous virtual pages act as storage units and virtual address of a segment is a permanent attribute. A protection domain acts as an execution environment for threads, each with access rights for specific segments. A concept of capabilities is introduced to support access control to segments and domains. Multiple domains can share the segments, given they have right capabilities. Inter-domain shared memory communication is done using RPC call facility and portals, which eases the sharing of pointer based data structures. Linking and code execution is done in a sophisticated manner using modified linkers. One key takeway from the paper is that, OS handles coarser grained system level actions like storage allocation, proaction and reclamation, whereas runtime systems and compilers handle fine grained control over applications.

4. Evaluation
The paper has evaluated the system by implementing a prototype on Mach 3.0 microkernel, where other OSes can co-exist. A good evaluation methodology with support of existing kernel primitives and runtime package is provided. A case study of Boeing CAD system, where opal was used for implementation of a integrated software environment is given in great detail. Prototype performance results of a tree-indexing program for three protection configurations are given. An inference that, overlapping configuration can provide same performance as a monolithic design with protection capabilities as safe as decomposed design can be derived. Also, some performance numbers (latency) are given for primitive operations (attach/detach, allocation etc,). A thorough study on related architectures is given which is much important for system comparison.

5. Confusion
What extra rights does ACL have compared to protection capability associated with a domain or segment? Curios about what major micro-architecture changes would be needed in the MMU as well as ISA?

1. Summary
This paper introduced the idea and implementation of a single-address-space operating system that provides easier and more flexible data sharing methods among different processes. It presented an experimental system Opal that adopts single-address-space model, with a series of well-designed protection mechanisms.

2. Problem
In this paper, the major problem rises in traditional model of private virtual address spaces for each running process: inefficient memory sharing. Without a single universal virtual address space, it is very hard to achieve direct memory sharing across processes.

3. Contributions
The paper designed and implemented the operating system Opal, which is designed to provide sharing and protection in a single-address space. Opal fully seperated protection from addressing, and many other mechanisms of a common operating system, in order to provide better flexibility in data sharing, storage and communication.
For different aspects in design of Opal, the paper contributed these ideas:
- Storage and protection
Opal uses segments, a set of contiguous virtual pages, as storage allocation and protection units; and uses threads as execution units, with a protection domain for each thread.
- Access control
In Opal, kernel resources are named by capabilities, and capabilities can be attached to a thread’s protection domain.
- Interdomain communication
Shared memory is the primary form of across-thread communications in Opal. The paper introduced the concept of portals that allow other domains to use the data.
- Protection domains
Parents protection domains in opal are able to share data with their childern domains, and run procedures flexibly in the childern domains.
- Executing code
In opal, a module with a symbol table, static data, and external symbols is defined to execute procedures. Multiple module instances can exist concurrently, sharing the module’s code but possessing different writable data.
- Resource management
Opal provides coarse-grained reclamation, leaving the detailed control to language level. It uses resource group for resource management. SegRefs are kept in each capabilities of a segment.

4. Evaluation
The paper implemented Opal on top of Mach, a Unix-like OS kernel, and evaluated the system with a practical experiment of Boeing’s CAD system. It also studied and compared different protection configurations. It was indicated that the overlapping organization is able to reach great performance without sacrificing safety.

5. Confusion
- Is there concept of “Thread” when this paper was written?
- The paper didn’t compare the performance of Opal with other existing systems when conducting the Boeing CAD experiment. why?

1. summary

The paper introduces the Opal operatin system which is a single-address system built to enable the efficient deployment of complex, modern programs on wide-address (64-bit) architecture. The paper mainly touches on the advantages that a single-address system has over a private-address space model and also explains the abstractions and primitives employed to achieve the various objectives.

2. Problem

In the traditional private address approach, efficient cooperation between processes is hindered as processes need to depend on operating system mechanisms such as pipes, files or messages to communicate with one another. With the rise of integrated software, that is individual programs that depend on extensive communication between one another, these mechansims are a bottleneck to performance.

3. Contributions

The main contribution of the paper is the design and implementation of a single address space based operating system which achieves efficiency in process communication through the judicious sharing of virtual memory. Specifically, the research introduces several ideas.

1. The logical Separation of Storage and Protection

This forms the basis of the Opal single address space system. Segments are the unit of storage allocation in Opal while capabilities form the basis for protection. This separation of ideas ensures that access and addressability are different in the single space address system and so ensures the integrity of data.

2. Interdomain communication

A protection domain is a set of specific segments which provides an executing context for threads. Control transfers between domains may sometimes be necessary and these are implemented through the use of portals. This allows threads to access data from different domains.

3.Resource management

Resource management is implemented through the use of resource counting. To this end, Resource groups are introduced which are the basis for a resource control policy and also enable bulk deletion of a group of related resources.Reference objects are also used to prevent untrusted threads from wrongly deleting shared resources.

4. Evaluation

The paper describes the experimentation done with the Boeing CAD software on Opal. Certain data such as the time to create a segment, destroy a domain is given. However, there is no comparison of the efficiency of the system to other private address space - based systems of the time.

The authors however give a qualitative discussion of the drawbacks of their system with the main drawback being the effciency problems that arise when data needs to be copied within an address space and the loss of contiguity in terms of address space. However, the authors conclude that these tradeoffs are reasonable price to pay.

5. Confusion

The concept of reference objects is unclear. Specifically, why would untrusted entities have the permissions to delete shared objects?

1. Summary
Conventional OSes present a bad trade-off between performance and protection, where applications can either be structured as multiple processes using message passing for communication while sacrificing performance, or as a single process sharing memory in a single address space with no protection. The authors argue for a single address-space OS that decouples protection from the process execution, and present the design of Opal, a single address-space OS, with abstractions for protection, memory, and communication.

2. Problem
To avoid this performance-protection trade-off, by designing a single address space OS, which enables easy sharing of data and procedures across execution contexts (processes), and also provide abstractions for protection and other basic OS primitives that the applications expect.

3. Contributions
The key contribution of this work is the systematic analysis of the benefits and drawbacks of the single address-space approach compared to conventional private address-space approach, and the proposal of OS abstractions for exploiting the advantages of single address-space approach. The protection domain abstraction enforces protection across execution contexts in this shared setting, where all the data and procedures are addressable uniquely by all execution contexts. The protection domain defines the access rights of the processes under them by specifying a set of memory segments with the access rights for each of them. The capabilities abstraction provides access control to resources in Opal, where a capability is simply a token that grants permissions to operate on Opal objects in certain ways. The portals abstraction enables communications across domains through remote procedure calls.

4. Evaluation
The authors evaluate the performance of Opal primitives like allocating segments, attaching/detaching segments and cross-domain RPCs, and compare some of them with the primitives of Mach, micro-kernel on which Opal was implemented, to show Opal does not add significant overheads to the Mach primitives. The authors also model a CAD application (target application) as a complex pipeline of producers and consumers, and evaluate a very simple producer-consumer workload to show the advantages of using shared memory instead of message passing. The authors fail to evaluate and compare the protection mechanism of Opal and conventional OSes.

5. Confusion
Other OSes provide primitives for using shared memory with the only caveat that the shared region could be mapped to different addresses, which the authors identify as a major drawback, although this can be overcome by using relative addressing or employing simple address translation. Are the authors' concerns real? The portals mechanism for providing RPC was not well-explained the paper.

Summary
This paper explains the memory-allocation and protection in Opal OS which uses a single address-space for wide-address (64 bit) architectures. The idea of Single address space is contrary to the conventional OS where every process has its own virtual address. The unique architecture and abstractions of Opal claim separating the concept of protection and addressing are key in a single address-space system. Memory allocated in the form of segments and execution happens in form of threads. Protection domain is the execution context for threads and it defines the access rights of the segments that belong in this domain.

Problems
The operating systems at that time used to follow the model of private virtual address space for each executing program, which ensured protection, but made communication between the programs complex and inefficient. . Private address-space systems complicate code and data sharing among multiple programs. Such strict protection among processes is hard to maintain in large datasets and applications. And thus a wide-address (64-bit) architecture allowed flexibility to use the available space to tackle issues in the old system.

Contributions
1. The 64-bit addressing facilitates a large virtual address space where multiple process can access the same code and data segment in a protected environment.

2.Common address space enables easy linking to data structures and code segments The base register address for private static data in Opal is provided dynamically, it leads to flexible protection relationship between instances

3. Memory can be shared read-only, used in restricted ways, or passed sequentially from domain to domain. Protection is guaranteed using protection domain which is an execution context for threads, restricting their access to a specific set of segments at a particular instant of time. ACLs and password capabilities are also used to further impose protection in Opal.

4. In Opal, all interactions are through procedure calls which leads to clean modular interface. Implementation of event managers and mediators also demonstrates the concept of modularity in Opal.

5. As there is global single virtual address space, Opal does not require pipes, files or messages to exchange data, thereby improving performance.

Evaluation
A full fledge application was picked by the authors in order to test the OS for all the theoretical claims of single space virtual address. The performance of Boeing CAD has been evaluated in three different configurations – Monolithic, Decomposed and Overlapping (tree-indexing program), The paper mentions that read-only shared memory is faster than other modes of communicating between processes such as pipes. The testing of Opal OS is convincing as compared to their claims made before building this system.

Confusion
How are page faults handled? The paper mentions briefly about the runtime fault handler. A bit more light onto this would be great

Summary
The paper explores the strengths and weaknesses of single-address space approach of the Opal's operating system, where a global address space was shared by all procedures and all data. It also explains how Opal's abstractions of protections domain, segments, resource groups and capabilities decoupled protection from problems of sharing.
Problem
The traditional address-space systems available at that time provided poor tradeoffs between protection,performance and integration. You can either place all the application components in independent processes that exchange data through pipes,files or messages, thereby sacrificing performance OR place all components in one process thereby sacrificing protection. So they wanted to design a system where a lot of processes can have easy access to a large dataset, for example a database.
Contributions
The main contribution of the paper is the design and implementation of flexible resource sharing and protection mechanisms within a single address space operating system.
Access to various segments is defined by the protection domains in which the threads are executed. The protection domains can overlap and each thread can access only segments as determined by its segment capability. This forms the basis of protection and easy sharing of data across processes. Resource groups and Segrefs provide restricted access and prevent premature release of resources by malicious programs. There can be a considerable reduction in cache costs as virtual-physical address translation tables need not be maintained for each process. The run-time addresses of a module are globally fixed as they are statically linked into persistent systems. Therefore any thread can dynamically attach and execute simply by knowing its address.
Evaluation
Opal server was built on top of a Mach 3.0 microkernel system. The papers discusses the Boeing's CAD system and compares the performance of the application in three configurations Monolithic,Decomposed and Overlapping; and confirms that the performance benefits of sharing. The papers states that the time taken for domain creation, execution and destroy were on par with equivalent operation of fork/exec/exit operation on Unix.The performance numbers of Opal primitives such as segment creation, attach/detach segment were also provided.
Confusions
What is the added advantage of having a mediator?

Summary
The article discusses the Opal prototype over the Mach 3.0 microkernel. The prototype harnesses the space and flexibility of a unified 64bit virtual address space common to all threads running on the system. While doing so it efficiently decouples addressing from protection by using the concept of protection domains, ACLs, passwords and a few other other mechanisms. The authors argue that this enhances cooperation and improves reliability and performance of applications manipulating large persistent data structures.

The problem
The authors argue that private address space operating systems suffer from poor cooperation between protected application components. The developer is either forced to communicate between disjoint modules using application neutral mechanisms like pipes or files or is bound to put all the components in a single module. The first approach sacrifices performance while the second relinquishes protection heavily. By making virtual addresses context independent and access rights dependent on the protection domain of the thread, the authors propose that such a system will be simple, efficient and highly performant for hugely distributed systems like CAD and CASE.

Contributions
Proposal of a single unified 64-bit wide virtual address space common to all executing threads
Threads execute under protection domains which determine access rights
Basic unit of storage in memory called a segment which are contiguous extents of virtual pages
Exchange of address pointers now possible across the network because of a common address space. Authors propose to extend the addressing domain across a small workstation network cluster.
Fine-grained protection should be the prerogative of modern type-safe languages. Operating systems should rather concentrate of hard boundaries (coarse-grained protection). This is easily supported on modern processors that have page-based protection mechanisms.
Given the capability, a thread can attach a segment to it’s protection domain in turn enabling all other threads in the domain access to it. A detach operation is also present.
Interdomain communication is permitted in a controlled way by the mechanism of portals. Threads enter the foreign domain at a fixed code location thus the creator of the protection domain controls which code gets executed upon entry by a foreign thread.
Opal’s modules are linked to execute at different addresses at runtime though they execute at the same address subsequently. The modules are statically linked.
Resource management is done using the mechanisms of resource groups and reference objects.

Evaluation
The prototype was evaluated for a tree-indexing program using mediators for three different configurations. The configurations are the monolithic configuration (which resembles a single unix process that sacrifices safety), the decomposed configuration (in which two domains interact using RPC while heavily sacrificing performance) and an Opal styled overlapping configuration (in which the produces and consumer data segments are overlapping). It was noticed that the Opal styled overlapping configuration though as safe as the fully decomposed configuration is as performant as the monolithic configuration.

Confusion
What are password capabilities exactly?

1. Summary
The authors introduced the Opal, a 64-bit wide, single-address-space operating system that targets to improve data sharing among executing programs while persevering protection. The global virtual address space is shared among all threads to enable shared memory while data accessibility is controlled by protection domain associated with threads.

2. Problem
In an integrated task (like Boeing CAD), processes may need to interact a lot, causing a lot of data sharing and transferring. However, existing UNIX system back then only supported interprocess communication (IPC) by message, file or pipe, which are inefficient. Furthermore, private addressing space, although improving data protection, hinders IPC. New mechanisms are called to improve data sharing to satisfy industrial need while keeping data secure.

3. Contributions
The key idea is the separation of protection and addressing. Specifically, data protection is realized by protection domain rather than isolated addressing spaces, so that all executing programs can share a single address space.

The continuous address space allocated is called a segment, and an executing program is called a thread. All threads share the single address space but can only access certain segments permitted by protection domain associated to each thread. A thread can start/stop accessing a segment by simply attaching/detaching it to thread protection domain if kernel grants segment capability to the thread. Protection is ensured between threads.

To share segments among threads, one thread consults the protection domain in charge of that segment via a portal, and accesses the segment through entering the portal upon conferment. This sharing mechanism also works for client-server model in which clients ask to enter server’s portal by RPC calls. A protection domain can have several portals and each could handle several thread objects.

A parent thread could manage all capabilities of its child thread but not vice versa, which help structure the domain the segments and facilitate cooperating threads.

Linking and loading modules must be modified to be static to avoid overlapping address spaces. Resource groups manage resources including reference objects, which counts references to a segment to prevent untrusted release and facilitate reclamation. Resource groups can also be in a tree hierarchy in which subgroup’s resource is managed by parent group.

4. Evaluation
The authors could have developed a stand-alone operating system that implements their single address space idea, but (I reckon) the formidable workload made them build Opal prototype upon Mach microkernel, which makes Opal looks like a process and threads what we call threads today. The paper demonstrates the feasibility of such Opal system can interact and communicate with host UNIX system.

It especially argues the application of their design in Boeing aircraft CAD and associated database. Without actual implementation, it lists the potential benefits from their design.

They implemented a framework of their design on mediators. And the result shows that their overlapping/sharing address space works better compared to decomposed private address space. However, both evaluations are on modified mediators, which I disagree because I think private address space (decomposed) evaluation should be carried out in original mediators. Besides, cleanup shows to take most of time because segments are spread over the global address space.

They mentioned issues in their design, including segmentation problem in single address space, reclamation segment recourses, fork semantics (which is resolved by Pthread), and unavoidable copy and incompatible copy-on-write.

5. Confusion
I am very curious to know whether this paper motivates the concept of what we call ‘thread’ today. When I was reading the mechanism part, I feel like this design is going to the other extreme of sharing while UNIX at that time was at the extreme of protection and isolation. Their main idea, which is to replace of UNIX private address space module, was not adopted by the industry. However, it is interesting to notice their implementation actually shows compatibility of threads sharing data within a process on existing UNIX systems, which looks very similar to what we do nowadays. Also I would like to know if shared memory is another contribution of this paper to interprocess communication. It is implied from context that back to that time IPC did not include shared memory. Even though shared memory is designed for threads, we use it between processes because data sharing among threads is inherent in nowadays design.

Summary:
This paper talks about the design and development of a single-address space operating system called Opal which was built on top of the mac 3.0 micro-kernel.

Problem:
The authors feel that though private address spaces served the important purpose of granting each process a large enough virtual address space in the days of 32-bit architecture, with the advent of wide-addresses the scarcity of vitrual addresses is no longer a problem and so the coupling of addressing mechanism with the execution mechanism (i.e. processes) serves only to make sharing data across execution contexts unneccesarily expensive.

Contributions:
The important points about the mechanisms in Opal that are presented in the paper are:
-The usage of a single large address space across the entire system: Even though this was already done in several systems, the authors feel that with the arrival of the 64-bit architecture, this approach gains significant advantage. They talk about how such an address spacce ( shared across all executing contexts in the system/all nodes in a LAN ) can significantly improve both the ease and performance of sharing data (by directly passing virtual addresses instead of copying data), especially for systems with multiple processes collaborating and sharing large amounts of data.
-The decoupling of protection mechanism from the execution environment ( process/ threads), ownership, resource naming and virtual storage.
-The implementation of coarse-grained control of storage, protection,and resource management etc. at the OS level, leaving finer-grained control to the applications themselves.
-Static linking of modules into the global virtual address space and register relative addressing of private static data(due to absence of private virtual addresses)
-Usage of password-capabilities(passed directly in memory) for access control
-RPC mechanism for calls across protection domain boundaries through 'portals'.

The authors' implementation of the Opal prototype was done on top of a Mach 3.0 microkernel which was also housing a Unix system in parallel.

Evaluation:
-The authors talk about the time taken for creation of memory segments and how, through caching, the time was cut down. But overall the performance of primitives such as creation of a new domain etc. ( analogous to fork) are no better than the corresponding calls in Unix.They argue that this was because of the lack of tuning in their implementation and the inherent trade-offs due to building Opal on top of a kernel ( Mach) which was built with private address space systems in mind.They state that with the resolution of these issues, performance should improve considerably.
- But more importantly, they compare the performance of the boeing CAD system on Opal with overlapping domains (allowing direct access of pointers across them) and on, what they call a 'simulation' of unix, i.e. running the collaborating processes in fully 'decomposed' mode in Opal(disjointed protection domains). As we can expect, the overlapping domains configuration performs better. It actually performs as well as the monolithic configuration ( a simulation of placing all the tools in the same unix process), but without the accompanying protection loss. While the measurements made on an actual Unix system instead of a simulation would have been better, the data does appear to vindicate their claim of considerable improvement in performance.

Confusions:
- Password capabilities are stated as being not maintained by the kernel. Who then enforces access control on the capabilities themselves?

1. Summary
This article describes the Opal operating system, which uses a single shared address space as opposed to the multiple virtual address spaces used in Linux. This enables simplified sharing of code and data while protection is handled by protection domains for segments of memory.
2. Problem
As applications (CAD, etc) became more interdependent on large data sets between processes, the creators of Opal looked to implement an OS with a single 64bit shared address space, with protection decoupled from addressing. Difficult to share private address spaces caused data sharing to need pipes or messages passed between processes, a problem which would be solved by treating memory as a single global resource.
3. Contributions
All data in Opal resides in segments, which can be attached to a protection domain (the Opal analogue for a process) given the proper permissions. Memory can be shared between domains, which is the primary form of communication.
Opal has no "conventional" programs, all code consists of shared procedures that reside in a single address space. Procedures can be shared between processes as long as the caller and callee are in the correct protection domains. This capability is implemented in the form of Portals, which allow an RPC style call from a "client" domain into a "server" domain.
Since processes no longer exist in separate virtual address spaces that can be simply reclaimed upon program exit, Opal uses reference counters and resource groups to reclaim resources.

4. Evaluation
An Opal prototype was implemented on top of the Mach microkernel and used to experiment with the single address space model. A producer-consumer tree indexer was built and evaluated using three different memory protection arrangements. Using read-only memory shared between domains, the authors showed a performance gain compared to the traditional Unix model of RPC/pipes between processes/domains. This testing seems lacking though because the RPC style arrangment was implemented in Opal, which the authors admitted to not optimizing for performance. It seems like the inter-domain RPC calls simply could have carried programming overhead that was not as optimized as the shared memory model in Opal, and since a pure Unix implementation of the test was not run it is hard to say conclusively.
5. Confusion
When the Opal prototype was implemented on top of Mach, it seems the "single address space" referred to actually a private virtual address space provided by Mach using the "standard" memory model. If this was the case, was the functionality that relied on cohabitation with Unix operating using standard message / pipe based architecture, and presumably incurring the performance penalty that entails?

Summary:

The authors describe the Opal system, which is a single address-space operating system targeted for 64-bit address space architectures. It is in contrast to the UNIX private address space concept, because here the main goal is to achieve full separation between addressability and access. Due to this separation, protection does not cause obstacles for sharing and hence performance increases without any hit on protection in integrated software programs. An implementation on a microkernel is also described.

Problem:

The authors argue that with private address spaces it is extremely difficult to achieve good tradeoff between protection, performance and integration or sharing. This is because protection and addressing are tightly coupled and hence if the processes are completely protected from each other, then it hits the performance of sharing information between them. They want to address this problem by using a single address-space and hence providing mechanisms to share data without any hit to protection.

Contributions:

With the advent of 64-bit architectures, there is no need to reuse the virtual addresses and hence each process doesn't need a private address space. Instead, if the addressing is global and unique then it can help in building better abstractions for sharing while still not losing protection between two threads of execution.

Pages of memory can be shared between processes dynamically and no a priori decision is required. Several abstractions have been developed to achieve the goal. The virtual memory is managed in units of segments. Protection domains are encapsulation of sets of procedures with access control relationships between them. A portal provides an interface to a protection domain.

Evaluation:

An Opal prototype is developed on a Mach microkernel. The Opal abstractions are built using the Mach primitives, though it caused some performance loss. They experimented by implementing a tree-indexing application in three different configurations and found out that the Opal overlapping organization is almost as fast as the monolithic configuration without sacrificing protection.

Confusion:

Why isn't this system or variants of this not seen in widespread adoption today?

Summary:
The paper introduces Opal, a single address space operating system which allows efficient sharing of code and data among threads. It decouples address space from protection. Opal could cater to complex systems like Boeing applications, CAD, image processing etc. The paper compares and contracts single shared virtual address space with traditional private address space. At the end, its co-existence with multiple environments is demostrated.

Problem:
Existing systems (based on 32-bit architecture) which used private address space had to trade off between performance and protection for integrating applications. Other capability based systems are heavily hardware dependent for protection and object oriented design. Opal explores the idea of single shared address space to harness wide-address architectures eliminating need of reuse of addresses and decreasing translation overhead.

Contributions:
1. uniform interpretation of addresses leads to efficient sharing of code and data among processes.
2. Separation of Address space and protection increases flexibility, allows dynamic imports and binding to data structures and code. It improved both protection and performance. Hence, no more trade-off required.
3. Protection domains for segment-level protection. Passwords and ACLs are also used to strengthen protection.
4. Improvement in performance as no more pipes, files or messages are required to be exchanged between processes.

Evaluation:
A prototype was implemented on Mach 3.0 microkernel which had other systems such as Unix on it. This showed that Opal could co-exist with other operating system environments. Various protection configurations (monolithic, decomposed and overlapping) have been tested for tree-indexed program and shown that decomposed configuration performs as good as monolithic and read-only shared memory is more efficient than pipes, files etc. Overall, the authors were successful in showing how performance was not hit in comparison existing OSes.

Confusion(s):
Confused about the linking module used to execute a module in different domains.

Summary:
The paper mentions the various features and abstractions in the Opal, a single-address-space OS, mainly focusing on the sharing and protection. The authors provide a prototype implementation of the OS model and justify the design by outlining the features that makes the model suitable for certain types of workloads. Finally, some of the limitations of the approach are mentioned and the authors claim that the trade offs were reasonable given the large address space (64-bit addressable).

Problem/aim:
Through this approach, the authors aimed at providing an OS for integrated software environments that including data centered tools. Their intent was to exploit the large address space and make efficient communication between protected processes possible by separating the addressing and protection mechanisms which, the authors claim, wasn’t possible with private address space systems.

Contributions:
The basic underlying feature of the Opal model was that it treats and controls all the address space as global resource such, like disk or main memory. The authors claim that the problem of reclamation of space was simplified by separating the notion of protection from other concepts tied to the notion of ‘process’. The concept of protection domains, consisting of execution threads, which had access to specific segments, formed the basic building block of this model, and all the primitives and routines were built on this. This is similar to the concept of minimalistic kernel design where the OS provides only higher level implementation primitives and finer policies are left for the users. Another key concept was ‘capability’, which was the handle for objects such as the segments. Capabilities were realized through passwords in Opal, and determined the access permissions for objects. Inter-domain communication was realized through portals, which was created by domains that wanted to allow other domains to access protected data. The proxy and guard objects along with capabilities facilitated this communication. An interesting protection feature was the parent being able to protect its data by spawning a child in another protection domain. Resource groups allowed the OS to ensure no domain over utilized resources.

Evaluation:
The Boeing CAD system is used to showcase the performance of the Opal OS model. As indicated by the graph, the model’s performance is on par with monolithic configuration, yet providing protection at the same level as the decomposed configuration. The authors have used their prototype of Opal running above Mach on DEC3000 to demonstrate that the approach could be used to build an OS over a microkernel. The values of time taken for some basic routines, such as creating a domain, cross domain call etc., are provided and contrasted against the Unix programs and the native Mach. These give an estimate of the overhead caused by Opal’s implementation of concepts, ex. capabilities.

Confusions:
It is mentioned that a given module continues to reside in the same address every time it runs. Does this imply that a module can never be replaced from the single-address space, what happens in case of a memory shortage?

Summary:

The paper talks about how a single global virtual address space can be used to improve the performance for integrated applications where multiple components have a lot of dependency on one another. The paper tries to justify a single address space architecture by trying to compare its benefits and drawbacks with that of a private virtual address space architecture.

Problems:

OPAL tries to improve the performance of processes which involve a lot of interprocess communication and while trying to do that they also try to decouple protection and addressing with the goal of making it more flexible.

Contributions:

The paper has provided a different way to look at addressing within a system. They have achieved high performance on IPC using shared memory concept. The global address space has been divided into segments as required by the threads with each of them executing in their own protection context. This context is what restricts non-trustworthy program from accessing segments of another program. Capabilities are used to get access to segments. Reference counts are maintained for each segment and within each of the segment capabilities to make sure proper cleanup could be done.

OPAL has addressed the need of different instances of same module requiring their own static data by using base register concept. The OPAL linker takes care of loading the module at different address within the shared virtual address space. One other contribution of OPAL was the usage of resource groups making it easier to bulk delete resource and also helping in accounting as to which resource is being used by which process.

Evaluation:

OPAL system has almost all the functionalities available in UNIX or any other OS using only a single address space. The usage of MACH microkernel to implement the OPAL system prototype helped somewhat to justify the proposed single address system. But as the paper itself points out there are quite a few drawbacks of single address system and they haven’t found any resolutions to those.

Confusions:

The paper speaks about extending the concept of single virtual address space to a distributed environment. I was not able to understand how would they make this possible? As I believe they would have to pass the data structures across nodes unless they have address mapping.

Summary :
The paper talks about Opal, an operating system that uses a single shared virtual address space for all the processes in a system. It highlights the major abstractions of Opal and their mechanisms which include the protection domains, segments, resource groups and portals. It also discusses the various tradeoffs between single address space and private address spaces.

Problem :
For applications that use large pointer based data structures, the overhead of copying the data through message passing using pipes, files etc. reduces the performance of the system. The problem is to develop mechanisms for processes to directly access the segments of a single address space that results in better performance along with providing proper mechanisms for memory protection.

Contributions :

1. Context independent virtual address spaces such that any process/thread that uses the virtual address would resolve to the same data at all times. It avoids the need to decide what is to be shared and what is private unlike mmap.
2. Virtual address space allocation is segment based. There exists a clean separation between the concepts of protection and addressing. Protection is achieved using protection domains. They form an execution context for threads and define the segments to which these threads have access to.
3. The concept of capabilities denote a set of rights to access a particular resource. All the resources including segments and protection domains are named by capabilities. The segments could be attached or detached as necessary by having these capabilities.
4. Portals allow threads running in different protection domains to transfer from one domain to another using a portalID.
5. Management of segments is done by keeping track of the reference counts.
6. They discuss a simple implementation of the Opal server on the top of the Mach microkernel wherein the mechanisms are mapped to entities in the Mach kernel. Protection domains are mapped to tasks, Segments to memory objects and mach ports are used to implement portals.

Evaluation :
The authors have identified that this kind of a single address space OS is useful for improving the performance and scalability of integrated applications that use so many pointer based data structures. They have demonstrated the use of Opal in the Boeing CAD system. In addition, they have evaluated the performance of the system with respect to metrics like segment creation time, domain creation time, cross domain call time. In a few cases, they could compare it to the equivalent call on a private address space system and have achieved reasonable results.

Confusions :
I did not get the main advantage of using the hierarchy in the resource groups. The intricate details of the refine and resolve procedures in the linking module weren’t quite clear. How are concurrency issues dealt with in this case?

Summary :
The paper talks about Opal, an operating system that uses a single shared virtual address space for all the processes in a system. It highlights the major abstractions of Opal and their mechanisms which include the protection domains, segments, resource groups and portals. It also discusses the various tradeoffs between single address space and private address spaces.

Problem :
For applications that use large pointer based data structures, the overhead of copying the data through message passing using pipes, files etc. reduces the performance of the system. The problem is to develop mechanisms for processes to directly access the segments of a single address space that results in better performance along with providing proper mechanisms for memory protection.

Contributions :

1. Context independent virtual address spaces such that any process/thread that uses the virtual address would resolve to the same data at all times. It avoids the need to decide what is to be shared and what is private unlike mmap.
2. Virtual address space allocation is segment based. There exists a clean separation between the concepts of protection and addressing. Protection is achieved using protection domains. They form an execution context for threads and define the segments to which these threads have access to.
3. The concept of capabilities denote a set of rights to access a particular resource. All the resources including segments and protection domains are named by capabilities. The segments could be attached or detached as necessary by having these capabilities.
4. Portals allow threads running in different protection domains to transfer from one domain to another using a portalID.
5. Management of segments is done by keeping track of the reference counts.
6. They discuss a simple implementation of the Opal server on the top of the Mach microkernel wherein the mechanisms are mapped to entities in the Mach kernel. Protection domains are mapped to tasks, Segments to memory objects and mach ports are used to implement portals.

Evaluation :
The authors have identified that this kind of a single address space OS is useful for improving the performance and scalability of integrated applications that use so many pointer based data structures. They have demonstrated the use of Opal in the Boeing CAD system. In addition, they have evaluated the performance of the system with respect to metrics like segment creation time, domain creation time, cross domain call time. In a few cases, they could compare it to the equivalent call on a private address space system and have achieved reasonable results.

Confusions :
I did not get the main advantage of using the hierarchy in the resource groups. The intricate details of the refine and resolve procedures in the linking module weren’t quite clear. How are concurrency issues dealt with in this case?

Summary:

This paper describes the approach to use a single address space model on a wide address architecture. The paper describes Opal’s support for sharing and protection. The paper discusses in detail about the mechanisms and abstractions provided by Opal for storage, protection, access control and inter domain communication. Also the implementation details of the Opal system prototype on a Mach 3.0 and its performance is studied using a CAD system.

On a 32 bit architecture there was a need to reuse the addresses and there were needs to compromise protection, performance and integration. Also, because of private addressing, there is difficulty in efficient cooperation between protected components. Opal tries to tackle these problems by using 64 bit single address space model with the idea of separation of protection from addressing.

In my opinion, the biggest contribution was the idea of separating protection from addressing. To achieve this, Opal harnessed the 64 bit architecture by using a single address space model. By using a protection domain, the threads were restricted to access a specific segments in the address space. By comparing the segment capability, an executing thread can easily request and deny requests using the Attach and Detach options. Inter process communication is carried by using a portalID which is unique for each thread. By using a global name space for portals in cross domain calls become possible. By statically linking modules with global address space Opal provides threads with same module can execute in different protection domains. Address conflict does not occur when a thread dynamically attach a procedure as a single global address space is used. Resource control policy is maintained using resource groups. By maintaining counts to shared resources using reference objects an untrusted thread cannot decrease the reference count more than what was requested of it.

The authors build a prototype of the Opal over Mach 3.0 which is a microkernel. Opal was experimented with integrated environments developed by the Boeing Company and research engineers. The graph for the execution time of monolithic, decomposed and overlapping configurations of a tree indexed program shows that fully decomposed configuration is nearly as good as monolithic configuration. Also, it shows that read only shared memory is more efficient than pipes, files or RPC. The authors also compare the performance of Opal primitives with that of UNIX build over Mach. Though implementing Opal kernel as a Mach server entails some loss as Mach was designed to support private address space we find that that Opal primitives show reasonable performance.

Even before we hit the virtual continuity problem, how did Opal select a particular virtual address for a process? I am a little confused on how the ResolvePortal call works.

1. Summary
Opal is a single address space operating system for wide address architectures. It provides a single global address space for all processors and modules enabling dynamic data sharing, while separating addressing and protection mechanisms.
2. Problem
The paper tries to address the data sharing problems of private address space operating systems. In specific, it tries to reduce the overheads of message passing methods, enable pointer sharing and provide a runtime/dynamic data sharing mechanism, instead of depending on static data sharing pattern analysis.
3. Contributions
The primary contribution of the system is to provide a protection mechanism that is completely isolated from the addressing mechanism. To enable this, the entire virtual memory is divided into segments. A thread is associated with a protection domain, which is a collection of these segments. A thread can share data with other threads in its protection domain by attaching a segment to it.
The policy of providing only coarse grain control in OS and leaving the fine grain control to runtime is also emphasized in this paper.
To enable protection, each resource object is associated with a named capability. Each service has an Access Control List with symbolic names of the capabilities. Password capabilities are used to share capabilities across processes.
A portal enables one domain to communicate with another. Cross domain calls thus include a portal id, capability and an access check field. Resource groups are used to control resource reclamation and to guarantee fairness of a resource to the threads.
4. Evaluation
The prototype is built on a Mach system on a 64-bit DEC Alpha system, with the Opal operating through a server. A runtime package provides threads support. Their experimental analysis exposes several practical aspects of the OS. Their shared memory concept could not be completely demonstrated because of the data format differences between applications. But using mediators, the performance is compared with different protection domains and showed that using read-only shared data / monolithic domain could yield best performance for an application. But, a comparison to Unix system could have been helpful here.
5. Confusion
The author says, “operating system protection structures are not the right level to impose modularity”. I do not understand the concept of modularity in the context of protection here.

Summary:
This paper describes the design and implementation of Opal System, a single-address-space operating system designed for 64-bit wide-address architectures. The authors claim that such a system will enhance sharing, simplify integration, communication and persistence without any loss of protection. The system is implemented on the top of Mach microkernel and study of this implementation justifies the coexistence of Opal with other operating system environments. The paper also offers detail on the tradeoffs between single and multiple address space and how Opal is similar/different from previous systems.

Problem:
The authors believed that 32 bit address space although reasonable size for process will provide scarce virtual address space. The concept of private address space was inefficient for IPC and costly for sparsely used data structure. The idea was to use new 64-bit address space architecture which will simplify management of an address space, cleanup, integration, performance and reliability of complex, cooperating application.

Contributions:
1. Sharing is simplified because address space is not context-dependent. Uniform addressing allows easy sharing.
2. Separation of concepts of address space and protection domain. This make memory protection cheaper, easier to use and change.
3. Opal provides abstractions to applications: protection domain, segments, portals and resource groups. Protection domain determine the context in which a thread executes and its access rights to memory segments which are dynamically created and shared through message passing.
4. Shared memory significantly improves performance and scalability of integrated applications.

Evaluation:
A prototype, Opal was built on the top Mach microkernel Os to evaluate authors approach. The graph on performance of tree indexing program for three configurations (Monolithic, Decomposed and Overlapping) shows how an overlapping org. safe as fully decomposed config. is nearly fast as the monolithic configuration. Other performance measurements are also mentioned on Opal operations like segment creation, fork, exit, etc. This paper also do a comparison of Opal with previous systems and how authors made sure that performance was not degraded compared to previous system. Since, it was built on top of mach OS, we couldn't measure the performance of Opal alone.

Confusions:
Didn’t quite understand the publishing capabilities and concept of randomized check field

Summary:
The paper discusses mainly the idea of a memory sharing and protection support in a single-address-space operating system designed for wide-address (64-bit) architectures through support on modern micro-kernel OS alongside other environments on single-node.

Problem:
The multiple-address approach in operating systems is advantageous for applying hard protection boundaries, easy clean-up, and providing more virtual address space to programs; but is disadvantageous to efficient cooperation between protected program components. The problem is to design a single address space based operating system allowing better sharing across applications without any need for special-purpose hardware, or single type-safe language; without loosing any protection or performance of a multiple-address-space system; and without loosing the advantages of the multiple-address approach.

Solution:
Mainly can be summarized as:
1) All virtual address space as a global resource controlled by the operating system, like disk space or physical memory.
2) Independence of addressing and protection. Idea of overlapping protection domains as a way to share memory between protected applications.
3) Coarse grained storage allocation, protection, and reclamation at Operating System level.
4) Resources, such as protection domains and segments, are named by capabilities; a capability is a 256-bit reference that confers permission to operate on the named object in specific ways. Ex., Given a segment capability, an executing thread can explicitly attach that segment to its protection domain, permitting threads executing within that domain to access the segment directly.
5) Decoupled protection from program execution, resource naming/ownership and virtual storage.
6) Procedures and data can be shared at any time without requiring a priori address space coordination.

Evaluation:
Opal prototype implemented on top of Mach 3.0 kernel. Their hypothesis is that private-address-space systems encourage poor structuring trade-offs for these integrated applications, causing loss of protection and\or performance. Though the comparison with the Boeing CAD system shows the validity of this hypothesis, they haven't provided clear performance comparison numbers with UNIX or any other operating system with multiple-address space.

Learning/Confusions:
Overall, a very good paper that tries to address the shortcomings in their approach as well.
1) One important development is: In a distributed, persistent, single-address-space system, network nodes can exchange addresses directly through messages, and data structures can be directly saved on long-term storage and later accessed by other programs without the need to translate internal pointers.
2) "With the appearance of RISC ACM Transactions on Computer Systems, microprocessors with 64-bit addressing, we believe that this level of translation is no longer necessary." In multi-node environment this argument doesn't hold true, given the address includes the bits(mostly IP addresses, which could be 128 bit IPv6 address also) for identifying the files placed across network.
3) OS has the control over the address space instead of the applications. Is that really desirable?

Summary

The Opal operating system implements a single shared virtual address space, allowing for simple sharing of memory between processes. It separates addressing and protection, instead using protection domains to allow different processes to share memory but also maintain concurrency and consistency. Opal is built on a microkernel foundation and sits between Unix and system processes, which allows it to be implemented with existing hardware and operating systems.

Problem

At the time of writing, operating systems implemented protection by giving each process a virtual memory space. This has the disadvantage of making it much more difficult for processes to communicate with each other. One solution is using pipes, sockets or shared memory, however this is slow and expensive. A different solution is to bundle all parts of the application into one process, which has poor protection. These problems are especially significant when dealing with large, sparsely populated data structures such as databases.

Contributions

The major contribution of this paper is the concept of a single shared virtual address space by decoupling addressing and protection. Since memory cannot otherwise be directly shared between separate processes with individual virtual address spaces, we instead make all addresses share the same space.

There are several important abstractions enabling this address space which also make up the important contributions of this paper, notably:

• Use of 64-bit address space to allow many processes to use a single address space, without needing to reuse addresses
• Protection domain: an execution context for threads, which manages their access to segments and hence acts somewhat similarly to locks
• Portals: these act as entry points into protection domains, and are passed between processes to maintain security and control over memory
• Resource management is managed by resource groups and performed at coarse granularity, where groups are organized in a hierarchical structure, and reference objects which maintain reference counts to facilitate garbage collection

Evaluation

The Opal system falls short in several ways, notably the lack of addressing flexibility, complications of memory management and resource re-allocation (which is rare but sometimes needed) resulting in dangling pointers, and some instances where data cannot be shared and must be copied for protection or preservation reasons.

One important evaluation which the paper fails to address is how the Opal system compares to a threaded application, where multiple threads can access a process' virtual memory space without adding all the complication introduced by a new layer in the operation system. I am not sure however if threads in the early 1990s worked the same way that they do today; please see below!

Confusions

I'm confused about the implementation of portals. If a given process wants to share data with another process, how does it communicate the exact portalID required?

To what extent did modern threading exist at the time this paper was written? It seems like some of the problems solved here could be addressed by threads; were they not being used at the time, or did they work differently than they do now?

Summary: This paper introduced a new OS structure that all processes sharing a single address space. The new model can achieve potential performance gain when lots of data needs to be shared among processes while still maintaining strict protections for data that is not meant to be shared.

Problem: Existing operating systems have the policy that every process has its own private address space. While this simple design provides convenience in implementing protection and clean-ups, it makes it very expensive when two processes need some data to be shared. In such cases sharing can only be done via communication channels such as pipes and in most cases data needs to be copied. This is expensive and inconvenient.

Contribution:
1. The idea to make processes use a same address space to share data. As a result, in Opal, pointers in one process is still meaningful to other processes. Sharing data across processes comes with no extra cost.

2. 64bit-wide virtual address space. Their reason to make the address space large is to ensure that it is big enough to hold everything from all processes. Even though it is hard to think of 64bit when the size of memory averaged several MBs. But today this has already been common even on cellphones.

3. Protection. Each process has a protection domain that specifies what segments this process has access to. Each segment is maintained with a reference counter that counts how many protection domains have it on the list of accessible segments. A process can share one or more segments with another process by changing its protection domain.

Evaluation: The authors demonstrated that their work would be useful on certain workloads such as database systems, CAD systems, etc. They have also implemented their system on top of Mach, and measured the cost of some primitives. They showed that their the cost of the two designs are close. However they did not compare the performance of a same workload running on Opal and on other traditional OSs such as Unix and Mach. Therefore it is hard to judge whether their design would actually bring a performance improvement even to those workloads that should benefit a lot from it.

Confusion: Today the concept of threads is a collection of processing units belonging to some process sharing the address space of the process but with no protections from each other. Unix does not have threads until 1995. Is the notion of threads adopted by Unix actually inspired or motivated from this paper?

Summary:
This paper describes OPAL – single address space operating system which was designed to increase efficiency of data sharing across processes without compromising protection. Further, it tries to explores strengths and weakness of single address space approach and traditional systems which have private virtual address.

Problem:
Author claims that traditional systems which have private virtual address space provide isolation between processes but are not efficient in terms of sharing memory. Traditional systems can use slow mediums like pipe for communication and not sacrificing protection by having separate process or they can run many programs under single application in which memory sharing is done efficiently but sacrificing protection. OPAL tries to solve this trade off by guaranteeing improved performance without sacrificing protection.

Contributions:
1. Single address space improves performance of data sharing between processes. Direct accessing of pointers and objects from other process with sufficient rights is possible. Author extends single address space idea for distributed systems.
2. To provide protection between different execution units, author introduces notion of protection domain. Each thread executes in a protection domain and that domain defines access rights for that thread. To access procedures across domains idea of portal was introduced, which serve as entry point for domain.
3. In those days, operating system supported only static linking across modules. I found technique of attaching and detaching segments on run time quite interesting. With sufficient permissions any procedure can call any other procedure in system.
4. Introduces copy-on-write technique which is even used in today's file system like LFS or BTRFS.

Evaluation:
OPAL is implemented over MACH kernel using MACH primitives. Performance numbers for segment creation, communication across different domains is given, but author claims they are not good because of overhead of underlying kernel. Paper compares performance of tree-indexing program implemented in OPAL and traditional OS and there is not much difference between OPAL and traditional OS.

Confusions:
What is password capabilities?

Summary: This paper introduces the 64-bit single address space operating system Opal. It focusing on the memory sharing and protection support. The sharing is easy because addresses are context independent. The protection is easy because the addressibility and accessbility is separate. The prototype on Mach 3.0 microkernel is implemented and evaluated.

Problem: The appearance of 64-bit address space architectures makes the reuse of addresses unnecessary. It allows changes on how operating systems use address space. Previous operating system like Unix use private, virtual address space for each process. In contrast, a shared single address space, which separate sharing and protection, may make the interaction between processes much easier.

Contribution:
1. It provides a single address space structure so that the process addresses are context independent. This eliminates the communication between processes about the same data and makes the sharing simpler. It also separates the protection from addressing, it makes the interaction of processes more flexible, so that the directly share procedures and complex pointer-based data structures.

2. It uses protection domains (PD) such that the processes can interact by their PD by sharing and RPC calls. They use resource groups for policy control of the capability of resources.

Evaluation: They built a Opal server on the top of the Mach 3.0 microkernel system. The evaluation on both sharability and protection domain are reported.
For the sharability, they show the performance on an integrated software Boeing CAD system where rich data structures, pointers are used. Opal's shared memory structure reducing the communication among different CAD tools (in distributed system).
For the protection domain. Opal has the same speed with the monolithic scheme which has no protection.
However, the speed of basic Opal operations, i.e. cross-domain calls and fork, exit, are heavily influenced by the Mach microkernel system. So we cannot see how much improvement precisely.

Confusion: I am confused by the concurrency, when two processes with shared memory modify the same address, what will happen?

Summary
This paper describes Opal, which is an operating system that is built on top of the Mach kernel. The Opal system uses a global virtual addressing scheme, meaning each processes shares some part of the virtual address space. In doing this, Opal has separated the concept of protection between processes from the addressing of the processes. Protection domains are now independent of the address space of the executing thread and they determine the access rights and the memory segments associated with the thread. Because of this separation, Opal was designed to take advantage of a 64-bit address space by simply sharing pointers to data instead of copying data between processes.
Problem
The problem the creators of Opal were trying to solve was to more efficiently use a 64-bit address space that was becoming more common in systems at the time. Most systems did not properly use the entire address space, instead emulating 32-bit designs. Opal was an attempt to correct this by using a global virtual address space, which is shared between executing threads.
Contributions
Because of the radical change in design from previous systems Opal contributed many new features. The most novel contribution of Opal was the separation of protection and addressing in the system. Instead of each process containing its own virtual private address space, each thread shared the entire virtual address space and memory access was determined via protection domains. In Opal, units of storage are segments, and segments are made up of one or more virtual pages. A protection domain restricts a threads access to a certain set of segments in memory. Opal also provides the abstraction of capabilities to implement access control, meaning a capability gives permission to use an object within the system in a specific manner (read, write, etc). Because of the global virtual address space, the primary way threads communicated between each other was through shared memory. Threads can pass pointers to other threads, which can then access the memory directly instead of copying it into their own address space.
Evaluation
The paper covers various aspects of the evaluation of the system. More broadly, they point out that the Opal system is advantageous in environments where there are many programs that must work together to complete a task, such as in the Boeing example. They also compare the design of Opal to a monolithic program that has its own address space. They recognize that there is a tradeoff between isolation and efficiency in accessing memory, the monolithic design being every procedure call is mapped into a processes address space, which sacrifices isolation. The authors showed that, using the Opal system, they can achieve a similar level of efficiency in accessing memory to a monolithic system, while still providing protection mechanisms between executing threads. An example of this behavior is shown in figure 4 of the performance section.
Confusions
The overall design principles were relatively straightforward, however, the implementation of these principles was somewhat convoluted. I was confused about the notion of an Opal Server and how resource groups and resource objects worked to achieve the protection principles mentioned. Also, how Opal code modules linked into the global address space was confusing to me.

1. Summary
The paper describes about the implementation of the Opal operating system right around the advent of 64-bit wide architectures. Since the address space is sufficient enough for the allocation of many processes at the same time, the authors argue that a shared memory space would overcome a few disadvantages of the private address space memory systems.

2. Problem
Private address spaces have the inherent problem of no data sharing between two processes. In order to do so, pipes or other interprocess communication methods need to be set up which are considerably slower than just sharing data in the same address space. Also, with private address spaces, transferring pointers across address spaces does not make sense. To mitigate these problems, the authors propose a single shared address space for all processes where only protection would be the issue comparing with private address spaces.

3. Contributions
a) Construction of a single address space operating system which allows programs to directly share procedures and data structures. This also leads to the sharing of data across a network easily through pointers in a distributed system.
b) The address space is broken into pages and the units of execution are threads. Processes are called protection domains and they have information about which threads can access that protection domain. This gives protection to data across the shared space.
c) Communication across domains is achieved by passing a 64-bit entry point in the address space called portal-ID. At this point, the permissions for the thread are checked before allowing execution in that segment in the address space.
d) Code linking is done with original addresses in memory rather than virtual addresses as every executable maps on to different addresses in memory. Although this causes a few problem with allocating a continuous array of data.

4. Evaluation
The Opal server was built on top of the Mach 3.0 microkernel operating system. The authors motivate their claims by using references to the CAD and CASE applications. Thus, they present an evaluation from the Boeing aircraft’s CAD system. Also execution times for decomposed, monolithic and overlapping configurations of a tree-indexing program built using mediators is presented confirming that the overlapping configuration provides the speed of monolithic and the protection of decomposed configurations.

5. Confusions
What does the resource group keep track of? Does it keep account of the capabilities of a thread or of a resource?

Summary
This paper describes the Opal system which is built on a single large shared address space model. This system makes sharing of data between processes convenient. The paper presents a complete view from the need to design to implementation and evaluation of Opal.

Problem
The paper solves the problem of ease of sharing code and data among various processes within a system. The sharing mechanism in conventional systems is difficult and prihibitive due to the disjoint virtual address spaces of the processes. This issue is addressed in the paper.

Contributions
The authors propose a new approach to system design that can facilitate easy sharing of code and data and also make protection easy to manage. The proposal is to shift from a separate virtual address space per process to a single virtual address space system. This means that just having the pointer to a memory location and sufficient rights to access that memory is sufficient. There is no need to map it to its own address space for any process. The Opal system presented in this paper makes clear separation between protection and addressing. The Opal system is responsible for managing virtual memory in units called segments. Capabilities are references that give operating permissions on objects in the system. They introduce the concept of protection domains which is an execution context for a thread and is the unit of access control. A portal is an entry point into a protection domain. The Opal system also requires a different set of runtime packages for taking advantage of the single address space.

Evaluation
The Opal system is implemented on a microkernel. The authors demonstrate the use of their Opal system with an industry scale software application. A comparison of performance using different protection mechanism is presented in the paper. They show that it works best with using separate protection domains. They also perform measurements of certain primitives to make sure that the performance does not degrade much compared to conventional systems.

Confusion
The paper talks about publishing capabilities on an address fault. I did not understand what publishing means and how it helps.

1. Summary
It is an article introducing the architecture of the Opal single-address-space operating system, its design motivation and principles, implementation, performance and related issues. With this system, this article explores memory sharing and protection in a new aspect.

2. Problem
The problem comes from the mechanism of private address spaces model in OS, which obstacles efficient cooperation between protected application components. Designer has to either sacrifice performance or protection under this mechanism. To avoid the cost of memory copy in conventional systems, the Opal introduces single-address-space and domains to resolve.

3. Contributions
Opal provides a single global virtual address space that is shared by all procedures and all data, crucial is the full separation of addressing and protection. It provides sufficient addressing without multiple address spaces; no loss of protection in the single address space and easy cleanup for programs that donate share data. Problems with the use of sharing and protection can be simplified or eliminated. Opal also separates program execution, resource ownership and resource naming from protection domains.

The philosophy of Opal design includes storage allocation, protection and reclamation are coarse grained at the operating system level while fine-grained control is provided at the language level; flexible mechanism in attaching and detaching threads to a domain; using shared memory to achieve communication between threads in different protection domains, portals are used as interfaces for other domains; read-only symbols are bound to virtual addresses and private static data is addressed.

4. Evaluation
The performance of this operating system is evaluated by Boeing CAD System, which has heavy data exchange workload. The performance of Opal on this kind of workload is better as it is designed for. Besides, the tested Opal os is only a prototype and runs on Mach, which causes some performance loss compared to kernel-level implementation. As to this point, in my opinion, Opal also relies on Unix routine as described in the article, does it also gain benefits from these routines? Issues of single-address-space include the inability to use context-dependent addressing, programs not free to select address so that segments cannot grow and loses of contiguity and the author himself is not sure about how to define “enough” for address space. Because single-address is based on the assumption that address space is fairly enough.

5. Confusion
How does today’s operating system deal with process communication issues? Seems most of them still follow the traditional Unix way.

1. Summary
The paper discusses an OS named Opal in which there is a single address-space. Opal aims to separate addressing from protection by allowing virtual addresses to be independent of a context, resolving always to the same data. Protection is instead achieved on a per thread basis, only allowing certain threads to address certain data.

2. Problem
Opal aims to answer some questions about the strengths and weaknesses of a single address-space OS. The prevailing approach at the time was that of private virtual address spaces for each process. The authors note that this provides strict per process protection but limits inter-process communication performance. Additionally they argue that there is little flexibility in the current paradigm, either your data are in separate processes and must communicate ineffeciently or it must all reside in a single process and be unprotected.

3. Contributions
The authors suggest that programmers be allowed to have finer grained control of what data is accessible in their threads. They introduce the notion of protection domains. Each thread executes in a single protection domain which defines what virtual addresses are accessible to it. This allows multiple threads to have some shared addresses to avoid ineffecient inter-process communication like pipes or files. In order for this to be possible, a single address space is required such that pointers shared between threads will still be valid. In addition to sharing memory, Opal provides “portals” which allows threads to execute code in other protection domains by referencing some portalID.

4. Evaluation
The authors provide some statistics comparing Opal to the underlying Mach operating system. However, this doesn’t provide any reasonable comparison, only that Opal is “only slightly slower” than Mach. It gives no notion of how much faster single address-space OSes are. Even for the time this doesn’t seem like an impossible task, having some small benchmark suite of programs would have not been incredibly complicated.

5. Confusion
I’m a bit confused as to why this idea is not more prevalent.

Summary:
The paper talks about the memory sharing and protection support mechanisms present in Opal system which is designed for 64-bit architectures. It attempts to explain the objectives of Opal for sharing, protection and its abstractions. They attempt to create an operating system which treats all virtual addresses as a global resource as it is very large compared to earlier architectures. The authors also developed a prototype and shared with us their experience and performance reports.

Problem:
The paper claims that the multiple address space systems like UNIX have inherent restrictions which don’t allow the programmers to implement beneficial code and data sharing patterns. It claims that communication via pipes, files or messages make systems unstable, slow, unreliable, poorly integrated — performance trade-offs.

Contribution:
1. Opal is developed as a single address space operating system intended to support complex applications exploiting the 64-bit address architecture — i.e. a global virtual address space which is shared by all the procedures and data and maintained by the operating system. Hence there is no requirement of reusing the virtual addresses.
2. Any memory segment can be shared at anytime without any address conflicts, as the access control can be moved around domains. All code is available in that shared space. This enables more increased flexibility while lowering performance overheads during communication.
3. Opal provides the abstractions to the applications in the form of segments (memory units), protection domains, portals and resource groups whereas communication is handled through shared memory. Protection is separated from program execution, resource naming, address spaces (segments) and resource ownership. This feature makes memory protection easier to implement and modify.
4. Protection domains help to create applications which can co-operate through their protection domains via sharing and RPC calls. Resource groups are responsible for policy control ensuring that applications consume only their assigned quota.
5. The authors have implemented Opal over Mach OS which proves that single address space environment can co-exist over a microkernel.

Evaluation:
While running Opal over Mach OS, the applications were restructured to get improved performance and safety as compared to private address space systems. The paper provides timing data for various operations like creation of segments, communication and domain centric operations but they mention that these data contain the overheads of developing Opal over Mach OS hence doesn’t reflect the performance of an independent Opal system.

Confusions:
I was unable to understand the working of the linker and private static data in the Opal system?

Summary :
This paper introduces Opal, a single address space operating system where the authors focus on decoupling protection from addressing (unlike the private address space operating systems). As a result of this, sharing and inter process communication is much more simplified. The implementation of this is done on Mach microkernel.

Problem :
Operating systems that have a private address spar approach have a lot of advantages but they also have the following problems :
a. Pointers cannot be used or shared beyond the scope of the process that they belong to.
b. For sharing information, applications have to use components like pipes, files or messages. This badly impacts performance.
c. The other choice is to place all the components in one process, which impacts protection.
Opal tries to solves these problems by taking a single address space approach and decoupling protection from addressing.

Contributions :
1. The most important contribution of Opal was to separate protection from addressing. By doing this, programs can directly share pointer-based data structures without prior negotiation of address space usage.
2. Implementing protection as a separate module provides a lot of flexibility because it allows asymmetric trust relationships and direct sharing.
3. Abstracting the entire memory as a single global virtual address space which all the processes share unlike the private memory address model where each process has its own view of the entire virtual address space.
4. The idea of protection domains which define the execution contexts for threads and using capabilities to define protection like ACLs.

Evaluations :
The features represented in the paper are built in the Opal server which is run on top of the Mach 3.0 microkernel. The authors show that their system, inspire of decoupling protection and addressing performs the same as ant other monolithic application using the tree-indexing example performance graph. The paper also shows the different times taken for creation of segments, domains etc but there is a lot of overhead due to the underlying microkernel and it seemed hard to interpret these in any single way.

What I found confusing :
I did not completely understand the linking module of Opal. Also, when different threads access the shared segments, how are their actions synchronized?

Summary:
This paper describes Opal, a single address space operating system, designed for 64 bit architectures. The authors explain the need for single address spaces over many virtual address spaces with regards to performance while preserving protection and give an overview of how Opal implements this through it abstractions of segments and protection domains. An implementation of this scheme on a microkernel OS is described, and finally tradeoffs of this approach, like memory management, are justified.

Problem:
Though private address spaces have their own benefits they hinder cooperation between processes. Specifically there is the performance overhead of interprocess communication. The other alternative is to forego the isolation of virtual address spaces but that would sacrifice protection between processes. In Opal the authors try to converge the ideas of sharing and protection that are optimal for the performance of cooperating applications.

Contributions:
Decoupling addressing and protection was the major contribution that allowed for better sharing while preserving protection. Since processes have unique segments in the single address space this allows other processes to easily share data. Though the entire address space is addressable, protection is enforced by limiting access only to segments that overlap with a process’s protection domain. Access rights are easily granted by attaching segments on the fly which makes for dynamic sharing. The idea of resource groups with nesting encourages better resource management as the holder of the group can create and delete its sub resource groups. Resource protection is enforced by reference objects which prevents a thread from deleting the reference counts of other threads for that resource.

Evaluation:
An implementation of the Opal on top of a Mach 3.0 microkernel is used to evaluate the claims of the authors on better sharing and performance gains of the single address space scheme with protection domains. The sharability aspect is justified by showing how Opal meets the needs of an integrated software environment like the Boeing CAD system. More specifically how Opal facilitates the pointer rich data structures needed by the CAD system and how it allows a more efficient use of memory by reducing the copying and communication overhead between CAD tools on different workstations. The performance of an Opal application with protection domains is shown to be as fast as a monolithic scheme with no protection. The performance numbers of individual Opal primitives are also given but there is not a lot to glean from these as they may be influenced by the underlying Mach kernel’s performance.

Confusions:
How are concurrency issues managed by sharing memory? Is that something handled at the application level?

1. Summary
In the paper "Sharing and Protection in a Single Address Space Operating System", the authors put forth a novel idea of exploiting memory sharing and protection support in single address space operating system, Opal, designed specially for wide address architecture. The paper focuses on how Opal allows judicious sharing of virtual memory between protected components without compromising on modularity, and at the same time, can increase performance substantially without sacrificing protection.

2. Problem
While private address space increases memory size and provides isolation, it also makes cooperation between different private address spaces inefficient or impossible(like pointers). It also forces a poor trade-off between protection, performance and integration. This leaves the application designer with two choices: placing all components of the application in independent processes which communicate by pipes, files or messages (poor performance) or placing all components of the application in a single process(low protection).

3. Contributions
1) Use of a single address space operating system which treats the entire virtual address space as a global resource controlled by the operating system thereby increasing flexibility and eliminating address overloading
2) Protection domains can overlap and each thread can access only memory segments determined by its segment capability. This enforces module boundaries (protection) but does not impose modularity
3) Primitives to attach and detach to a segment which can be used by threads(similar to UNIX mmap except that the mapped address is determined the system and not the application)
4) Inter-process communication through direct shared memory by using RPC calls across domains that accesses the callee via portals
5) Resource management is done through reference objects which keeps the reference count for shared segments and resource reclamation is done either using explicit reference counts or bulk delete using resource groups
6) Using mediators framework to solve the integration problem(in terms of the data format) between the data producing tools and data consuming tools. Producer tools register the events they would like to announce with the Event manager and mediators register with the Event manager specifying events they wish to receive.

4. Evaluation
- The authors have evaluated their approach by implementing an Opal prototype on top of the Mach 3.0 micro kernel operating system.
- The results of using three protection configurations namely monolithic, decomposed and overlapping for the tree-indexing program shows how an overlapping configuration though as safe as the decomposed configuration is nearly as fast as the monolithic configuration.
- The execution time for various Opal operations such as segment creation, cross-domain calls and domain management operations like fork,exit etc. have been provided. Though the paper mentions that there will be substantial performance improvements over the Mach-based prototype by building a native Opal kernel implementation, it is not clear how much of this claim is actually true.

5. Confusions
- Each process is allocated fixed memory in the virtual address space and processes are not free to select their own addresses for their segments and segments cannot grow. How was this not a limitation even at that time? What happens if there is an increase in the number of segments?
- "Programs granted access to a shared segment are trusted to use it correctly; erroneous pointer references always result from incorrect use either by the thread that stored the pointer, the thread that followed the pointer, or the thread that deleted the pointer’s target." Can you explain what are threads that follow the pointer or threads that delete the target? Also, what is the rationale behind trusting the user program to handle pointer references? (I am not sure how this would work since Opal does not restrict user programs to be only in strongly type languages)
- How many protection domains are created initially by the Opal server? How is this value pre-determined by the Opal server?
- Grouping procedures based on guard type and creating a portal per guard type is not very clear to me.

1. Summary
This article describes the major abstractions and features of Opal, a single-address space operating system for 64-bit architectures. The authors claim that having a global virtual address space greatly simplifies data sharing without any loss of protection; especially for applications such as integrated SW development. A prototype of Opal is constructed on top of an existing micro-kernel and initial results are highly promising.

2. Problem
In a 32-bit architecture, virtual address space is a scarce resource that requires address reusing through private address spaces. This provides adequate isolation, but is inefficient for dynamic & flexible sharing of memory. In the era of 64-bit machines, address space is not a scarce resource; hence, the paper calls for a rethink on fundamental OS abstractions to achieve better sharing of data without any loss of protection.

3. Contributions
The key idea behind Opal is the decoupling of addressing from protection. The ability to address a page, does not allow one to access it. Contiguous virtual pages are allocated as coarse-grained segments. The execution context for a set of threads is called a protection domain. The protection domain defines the set of segments that can be accessed by its threads as well as the level of protection using capabilities. Opal allows multiple domains to have overlapped segments, allowing transparent access to shared memory. Segments can be added and removed from domains using system calls, providing great flexibility in sharing memory. For passing control between domains, they define RPC interfaces called portals. Portals allow the callee to define the beginning point of execution, providing security against malicious calls. In a single address space, the linking of executable code & data is slightly tricky. They use modified linkers which replaces memory references in object code to a base+offset addressing mode to bind the addresses to different, fixed locations in the global address space. Another big idea of Opal is its philosophy that the OS should perform resource-management at a coarse-granularity, leaving finer details to compilers and language-specific runtime environments. The OS will only provide the minimum guarantees of security & protection along certain hard boundaries.

4. Evaluation
An Opal prototype is constructed on top of the Mach microkernel where Opal abstractions are implemented using Mach primitives. Apart from being a proof-of-concept, this also proves that Opal can co-exist with other OSs on top of a micro-kernel. A few results are shared from this system. The graph on performance of a tree-indexing program was very convincing. It shows that Opal can provide the performance of a monolithic SW implementation with the same level of protection as completely decomposed SW. A few latency numbers are provided for basic operations such as segment create, domain create etc. It is difficult to interpret these numbers without a suitable axis of reference, plus these numbers are surely inflated due to the Mach micro-kernel overheads.

5. Confusions
Where does Opal fit in the OS-design spectrum (from micro-kernels to mega-OSs) that we discussed in class?
How does Opal synchronize accesses to shared segments?

Summary - This paper attempts to make the case for single address space operating systems, particularly for facilitating sharing and protection in integrated software environments running on wide-address (64-bit) architectures. The benefits of such an OS such as easy memory sharing and support for modular software while enforcing necessary protection as well as the limitations like inability to grow segments, complex space management are discussed in great detail.

Problem - The authors believe that while private, virtual address spaces are essential for reusing addresses in the smaller 32-bit architectures, they are unnecessary and even restrictive in terms of sharing data between interdependent processes. The goal is to exploit the vast 64-bit address spaces to simplify sharing and improve integration chiefly through by separating the concepts of addressing and protection.

Contributions - The major contribution of this article is the notion that 64-bit architectures allow us to lift some of the restrictions placed on operating systems and explore options beyond the conventionally effective solutions for memory management. Similarly, the distinction between addressing and protection, which seems intuitive in hindsight, is a key takeaway from this paper. The concept of shared memory to improve the performance of interprocess communication by enabling the sharing of pointers and minimizing the involvement of the kernel is also important, but this idea has been explored further in other works from this research group.

Evaluation - The performance of this novel approach has been evaluated by implementing the Opal operating system over a Mach 3.0 microkernel. The resources provided by the Opal system are built on top of existing Mach primitives, and this degrades the observed performance to some extent. The main result is that the performance of a tree-indexing application using overlapping Opal domains is comparable to a monolithic application with the same functionality, while additionally providing memory isolation and protection. The authors also report the time taken for various Opal operations like segment creation, cross-domain calls and domain management operations like fork,exit etc. These results are not particularly helpful as this is not a complete standalone implementation, and there are overheads for building this on the Mach microkernel.

Confusions - What is the purpose of the randomized check field in an Opal capability?