CS 736 Reviews - Spring 2017

1) Summary

Opal is an operating system prototype built on top of the Mach kernel that explores what a single address-space operating system may look like. Their design is intended to allow flexible yet protected memory sharing, which is important for many systems such as databases and CAD tools.

2) Problem

In current Unix systems, memory is shared via mmap. However, pointers cannot be shared. This leads to both difficulty in programming and poorer performance. Meanwhile, shared memory is critical for many appication's performance.

3) Contributions

The authors produce a flexible framework for both allocating and protecting memory to processes in a way that makes sharing significantly easier. Their design has a single address-space in which all processes live and claim memory (possibly permanently), which became possible with 64-bit architectures. Along with the single address-space, they detail a capability-based memory sharing scheme in which segments of memory can be defined with access control lists. This allows controlled memory sharing between processes. Moreover, since pointers are never ambiguous, pointer-based data structures can also be shared, allowing for higher performance.

4) Evaluation

The authors' primary objective in their design is performance. To this end, they build a prototype on top of the Mach microkernel. Their prototype actually lives as a Mach process and behaves as a service or platform on top of which to build and run applications. This allows faster prototyping. Memory allocation and protection mechanisms are measured for latency. Unfortunately, it is not clear how much faster a native Opal kernel would have been, so the results must be taken as an upper bound latency.

The authors also evaluate ease of programming in an Opal environment by exploring design patterns and functionality with a real application in the class they are targetting: the Boeing CAD tool. The case study suggests that a single address-space OS would be well-suited for programs that must extensively share pointer-based data structures.

However, in my opinion, the authors do attempt to demonstrate how broad this class of tools is. In other words, they demonstrate that their OS is better for programs that do use shared memory, but it is not clear that most programs would benefit from Opal in programmability or performance. Opal seems somewhat domain-specific

5) Confusion

Did the authors intend this to be used as a general purpose OS, or were they aiming at database workloads and CAD tools? How important is shared memory for most programs?

Summary
Opal is an experimental operating system where all code and data exists within a single, huge, shared address space for wide (64-bit) architectures. This was developed to evaluate the strength and weakness of single-address-space-approach to deal with systems and applications that have high memory sharing requirements. The operating system is then evaluated by building a prototype on top of MACH microkernel.

Problem
Isolating programs within the private virtual address space presents obstacles to efficient co-operation between protected applications and also leads to poor tradeoff protection, performance and integration.
The use of typical Unix style inter-process communication mechanisms such as pipes are inefficient and suffers from problems like trust relationship and adds complexity to the systems which can be avoided.

Contributions:

1. Single address space systems avoids the problems by treating all virtual address space as global resource controlled by the operating system. Single address space
2. All data in Opal resides in segments and shared memory is the primary form of sharing and communication between threads.
3. Main contribution was Separation of concerns between protection and addressing.
4. Dynamic imports and binding to data. structures and code.
5. Procedures an data are shared at any time without requiring prior address space co-ordination.
6. Idea of capability and protection domain as execution context for access control and memory protection.

7. Opal also introduces the notion of portals to be the primitive that transfers control between code execution.

8. Introduces the concept of resource groups for each thread to enable easy accounting and controlling resources for the thread.

Evaluation:
This paper explores the Opal system with Single-address-space Operating System for 64-bit architectures. It also lays down some of its tradeoffs and issues in pure single address space approach such as Virtual contiguity, conserving address space and Inability to assign different meanings to the same address, conserving address space.

Confusion:
I couldn’t understand the Linking and Loading part of opal.
I would like to know if there are any ideas/concepts that mainstream operating systems such as Windows and Unix borrow from Opal.

1. summary

This paper describe Opal, a single-address-space operating system for 64-bit address space architecture. They argue that the decoupling of protection and addressing can benefit the applications using shared persistent data structure, both performance and flexible protection.

2. Problem
The multiple-address-space system cannot meet the needs of 'integrated environment'. Because sharing is in need to reduce copying, save the memory capacity, and increase application bandwidth. But putting the shared object in a single process in traditional private-address-space system will hurt the protection and isolation. Thus, a new design that boost sharing with fine-grained protection mechanism need to be proposed.

3. Contributions
* Opal decouples the memory protection from 1) program execution. 2). resource naming. 3). resource ownership. 4).virtual storage.
* It can be extended to share the pointed data across network through the single-address-space, the single context, flexible sharing patterns and cross-domain RPC.
* The resource is managed in opal by resource capabilities, resource reclamation through reference counts, bulk deletion using resource groups and accounts.

4. Evaluation
* They compares the performance of different sharing configuration with mediator: monolithic, decomposed, overlapping. Overlapping setting which contains three domains is more beneficial. It reflects that read-only sharing is efficient without loss of
protection.
* The evaluate the performance of Opal primitives in the environment that no cached domains are available.

5. Confusion
1. How does the 64-bit help? They said wide-address architectures facilitate the single-address-space approach by eliminating the need to reuse address, does this mean 256-bit would be better?
2. Is something special for the implementation of thread in opal?

Summary

The Opal project aims at designing an Operating System targeted towards applications which are interdependent (lots of data exchanged for example) which manipulate a large shared persistent database of objects.

Problem

With the availability of wide-address architectures the address space available saw a huge leap and the opal project explores the idea of having a single global virtual address space. This would lead to much better data sharing and also switching between processes. But the main challenges are :
Separation of the processes (security and protection).
No extra complexity in clean up when a process terminates when compared to traditional systems.

Contributions

Using a single address space is not a new idea. But doing this without type safe languages and special hardware is how Opal stands out.

The main abstractions in Opal are :
Segments: Contiguous virtual addresses,
Threads: Units of execution,
Protection Domains: Execution context for threads equivalent to processes in traditional OSs.
Portals: Used for interdomain communications

Following are the two main mechanisms which are achieved using the above abstractions.
Protection and Access Control
The broad idea employed in Opal for providing protection in a single global virtual address space is to restrict the segments which the threads inside a protection domain can access.
Kernel resources like segments and protection domains have associated “capabilities”. Each capability is a 256-bit reference which lets access to the resources in different ways based on its value.

Interdomain Communication
This is achieved using shared memory and portals(entry points). Threads outside a particular using “portalID” get into this domain.

Evaluation

The paper provides an extensive evaluation of Boeing’s CAD system an “integrated software application” which is a set of tools that communicate frequently with each other but also need protection. It evaluates the speed(time taken) by CAD applications and shows that using the full set of capabilities of Opal: “moderators, shared memory on a single address space” the performance is almost as good as(sometimes better) as if the whole application is run as one big monolithic process. The paper also does a prototype benchmarking where it measures the time taken to perform various standard functions attach/detach, recycle and segment creation.

Confusion

The use of Mach micro-kernel primitives to build the Opal prototype (section 4.1) was not very clear to me especially the role of inode manager.

1. Summary
Opal is an operating system that executes code in a single virtual address space using protection domains, rather than in separate virtual address spaces for separate processes. This simplifies memory sharing and improves performance in certain cases.

2. Problem
In Unix-like systems, different applications may operate on the same data. They run in separate processes so that malicious applications cannot tamper with the memory of other applications. The processes can communicate through IPC using pipes, files, or messages, but these are inefficient. Sharing memory among multiple processes is more efficient, but pointers in the shared memory area may not be valid for multiple processes.

3. Contributions
The authors note that different procedures can occupy different "segments" of memory in a single virtual address space to achieve protection, instead of having a separate virtual address space for each procedure. Memory sharing is possible if each thread is associated with a protection domain, which defines the segments that the thread can access, as well as the thread's access privileges. Each segment should be large, comprised of several contiguous pages; the operating system provides protection at a coarse level, while programming languages provide more fine-grained protection for data.

Opal is implemented on top of the Mach microkernel. It allocates memory in segments using a single virtual address space and provides protection domains for threads. Since Opal protection domains replace the concept of processes in Unix-like systems, there is no concept of "programs" in Opal. Instead, procedures contain code, and a procedure runs in a protection domain after it is called by a user.

4. Evaluation
The paper contains microbenchmarks for Opal operations, such as creating a new segment and performing cross-domain calls. The paper presents an application at Boeing, which wants to run "CAD, CASE, image processing, physical modeling, etc." using Opal. The authors imply that the work is still in progress and do not quantify the performance improvement in this case. The evaluation is appropriate, but hopefully future papers show the performance improvement in production at Boeing.

5. Confusion
It is unclear why mediators (Section 5.2.1) are a good idea. The paper explains that mediators coordinate communication between tools, allowing the tools to evolve over time without having to worry about inter-tool dependencies. But wouldn't this lead to a quadratic number of mediators? And couldn't a change to a tool possibly result in changes to several mediators?

Summary: Evolution of address space architecture to 64 bits inspired authors to build an operating system (Opal) having single global virtual address space with aim to separate memory addressing and protection. The paper discusses mechanisms along with abstractions for storage allocation, storage protection, interdomain communication, access control, and resource management and reclamation to build such a system. It then evaluates the system implemented on top of MACH microkernel.

Problem: Multiple-address-space design for memory protection having programs isolated by private virtual address space offers poor tradeoff between integration and performance. Placing all components of an application in a single process compromises security, and creating all components as a separate process and then communicating between them is inefficient. Systems built later with combination of shared and private address space also had issues like ambiguous pointers, difficult to detect private data pointers in shared space, and unable to share private code pointers etc. These problems gave birth to idea of using single global virtual address space OS.

Contributions: 1. Uses the concept of single global virtual address to segregate memory protection from memory addressing.
2. Advocates storage allocation, protection and reclamation to be coarse grained at OS level.
3. Introduces capability and protection domain as execution context for access control and memory protection.
4. Notion of keeping code as procedures (not processes) in shared memory.
5. Low cost sharing of complex data structures and procedures through pointers.
6. Discusses potential issues with single global virtual address space.

Evolution: Implemented on MACH microkernel, Opal OS is compared with CAD database system of Boeing in monolithic, decomposed and overlapping modes and performs similar to monolithic configuration despite providing protection similar to decomposed which should have compromised its performance. The paper should however provide performance metrics in more diverse cases e.g. what will be system performance if implemented for a) a regular user and b) distributed system etc?

Confusion: How do password capabilities ensure safety?

1. Summary
Opal is a single-address-space operating system which is designed to leverage the benefits of wide-address architectures. Opal eases code and data sharing among processes, while still providing protection and without compromising performance.

2. Problem
With the introduction of 64-bit address space architectures, there has been an immense increase in the address space available in a system. Opal explores how this increase in address space available can be used to implement a single-address space system and examines its strengths and weaknesses. Opal System tries to improve the sharing reliability and performance among cooperating processes which share large complex data structures.

3. Contributions
The basic idea behind Opal system is that each address has a unique interpretation throughout the system. Opal system achieves this by the introduction of Protection Domains which completely segregate addressing and protection. Opal System also introduces the abstraction of segments for memory, portals for inter PD communication and resource groups for resource sharing and reclamation. One of the major contributions of this system is that it decouples memory protection from the problems of program execution, resource naming and sharing and virtual storage. Opal introduces the concept of capabilities to facilitate protection on Opal kernel resources such as protection domains and systems.
The paper demonstrates the implementation of Opal system on already existing Mach Microkernel by utilizing the concept of Mach task to implement PD and Mach memory object to implement a segment. Opal also permits to persist the intermediate data computed by processes, thereby easing the process of caching and reusing this data. Opal systems thus simplify sharing complex data structures between processes and considerably improve the performance of integrated systems.

4. Evaluation
The paper claims that the features provided by Opal systems are well suited for integrated software environments. It demonstrates that how such systems can easily fit into the Opal systems model and get enhanced performance. The concept and implementation of mediators is introduced to abstract away inter-tool dependencies and then measure the performance of Opal system. The paper shows that performance of Opal systems along with protection is as good as monolithic systems which lack the benefit of protection. It also provides the costs of Opal primitives in the analysis of its prototype. The paper also describes the insights obtained from the implementation of Opal kernel as Mach server by roughly quantifying them.

5. Confusion
• The Sharing and trust relations explained in section 2.1 were a bit unclear to me. I couldn’t get how the bulleted points mentioned in this section are “confining”.
• It is mentioned that single-address- space architecture can be extended to include network-wide data. How the addressing is handled in such cases?
• It was not clear to me what segment and domain servers are. They are just mentioned in interdomain communication

1. Summary
Opal explores a single address space operating system with the advent and popularization of 64-bit processors. They approach the problem by decomposing the “process” which binds addressing and protection in other operating systems.

2. Problem
The problem Chase et al. were tackling was the complexity of orchestrating applications in the current operating systems. They aimed at simplify integration and sharing and improve performance of such complex applications.

3. Contributions
Opal was implemented on top of the Mach 3.0 kernel and in doing so provided significant insight into the tradeoffs between the use of single address space and the private address spaces. The main contribution is analyzing the implications of splitting the addressing and protection elements in a system. By separating these elements, they are able to offer simple shared memory by having threads attach and detach memory segments. Additionally, Opal uses a new abstraction called portals to be the primitive that transfers control between code execution. It seems to just provide RPC with more rigid semantics to be more efficient with shared memory.

4. Evaluation
The evaluation of the prototype presents skepticism as they drive towards an application specific conclusion. While the single address space may benefit the use of CAD software by Boeing, the numbers presented only tackle this specific use case and seem to presume the savings will primarily come from the application. Furthermore, they describe shortcomings with the single address space approach, but rather than describe merits, they attack the use case as unnecessary and a wrong decision such as fork.

5. Confusion
It would be interesting to better understand how application design must adapt to better exploit a single address space and the resultant complexities in doing so. This seems like a segue to vertical integration between the operating system and the application rather than an overtaking approach as they try to portray it.

Sharing and Protection in a Single Address Space Operating System

1. Summary
This paper is about use of Single Address Space instead of Context based Virtual Addressing for wide-address(64bit) architectures. This design changes the process architecture, resource management and access control from the traditional unix system. The paper claims that use of single address space can improve performance without comprising protection, simplicity and modularity of applications.
2. Problem
The paper states that context based Address space hampers overall performance especially for applications involving inter process communication. The traditional mechanisms involve OS based primitives like pipe, RPC or shared memory. The paper discusses performance issues with these mechanisms and complexity they add to application design. The paper states that current Unix design prefers protection over performance.
3. Contributions
The paper has proposed Protection domain, Segments, Capability as replacements for Unix Process, Page table, Context based address respectively. A protection domain shares a common addressing system. All the threads & child domains share same addressing system. As the use case involves wide architecture, there should not be any shortage of addresses. This architecture identifies every resource with an in memory object handle called capability. Threads use shared memory to communicate across protection domains via portals. Threads attach or detach resources via capability. Access Controls are managed by both OS and Programming language used for developing applications. Protection domains can create child domains with restricted access rights to run untrusted procedures. This architecture simply has globally available procedures instead of unix programs. These procedures are shared globally and can be protected via access rights.
As protection domains access resources via handles, the OS bears the task of maintain reference counts for each handle. When the count drops to 0(zero), the resource is ready to purged from the system. The OS also maintains resource groups for each thread to enable easy accounting and controlling resources for the thread. The paper has also listed some downsides of single address space design. The issues include lack of memory address contiguity provided by context based address system (useful for large arrays), Copy-on-write optimizations in fork/vfork in Unix and ineffectiveness of Opal for 32 address system.
4. Evaluation The authors have described a prototype of Opal implemented as user level process on Mach microkernel. The prototype contains opal server(kernel), os primitives like threads, RPC, etc via C++ runtime service and compiler tools. The authors have tried to run complex softwares like Boeing CAD, CASE, image processing systems, etc. The paper claims that such complex systems are good indicators of performance gain. As this prototype is a simulation, the performance comparison doesn’t give any useful insight apart from the fact that Opal on top of Mach kernel gives similar performance to Unix.
5. Confusion
What is the purpose of studying such a research paper in Advanced OS class (Will this paper ever help us in any future work in Industry/Research)?
Impact of fragmentation because of use of Segments?
Didn’t understand the linking/loading part of the OPAL.

Summary
This paper explores the Opal system with Single-address-space Operating System for 64-bit architectures. The goal of the authors was to restructure the OS to improve organization of systems and applications which have higher memory sharing requirements; they focus on enhancing sharing features, application integration, performance and reliability. Opal was an experimental project to explore the strengths and weaknesses of single-address-space systems.

Problem
Below are some of the problems/issues which Opal is trying to solve.

1. To demonstrate advances in hardware, OS, programming languages enable us to achieve similar goals of previous OSes, but without special hardware or less of protection or loss of performance or using only a single type-safe language.
2. Multi-address space (Private address-space) systems cannot share information across processes using pointers; As entire address-space is specific to each processes, pointer in one process might mean nothing (or even worse--accessing unallocated page) in the peer process.
3. In Multi-address-space systems, large applications with multiple components either have to run as separate components by sharing data through pipes, files or message (inefficient due to data copy--lower performance) or all components in one process (efficient, but with compromised protection). Opal tries to provide both!
4. Sharing in private address-space systems much be decided statically.
5. Private pointers in shared memoery is hard to detect.

1. Separation of addressing and Protection.
2. Opal introduces a single-address-space system in which all processes (protection domains) reside in the same address space to ease and provide efficient memory sharing and protection facilities.
3. Single address space approach allowed Opal to have dynamic binding of data structures and code
4. Any part of the code and data can be dynamically attached without prior decision (no static linking)
Large single address space can be extended to accommodate persistence and distributed data if needed.
5. Programs can share procedures and complex data structures through pointers
6. This paper introduces to the concepts of protection domains (kind of processes), capabilities (named resources), portals (cross domain invocations), Resource groups (protection domain's resource usage) and Reference Object (reference counter); These abstractions enable Opal to support overlapping protection domains, communication through shared virtual storage and protected procedure calls.

Evaluation
The paper discusses few quantifiable evaluations; A tree-indexing program is evaluated on Monolithic, Decomposed and Overlapping approaches. The decomposed approach with RPC calls runs in linear time with 128k size records against seconds. Where are both Monolithic and Overlapping approaches run at sub-linear time. The authors show that Overlapping approach provides both safety and performance. As the entire paper revolves around sharing of data among processes (domains), they totally ignore how independent processes might run in this system. Authors, as stated in the introduction, do discuss disadvantages of single address space systems: loss of Virtual Contiguity, Inability to assign different meanings to the same address, Conserving address space.

Confusion
Is it justified to introduce single address-space system for better sharing ? Isn't mmap in unix doing the same (no data copy) ?

With segments distributed in memory (no virtual contiguity), How does Opal takes care of various bounds that it has to check for each address generated by a protected domain ?

Summary
The main goal of Opal experiment was to design an OS to improve the performance of highly cooperative applications without sacrificing protection. This is achieved through flexible sharing among processes by running them in the same virtual address space using abstractions like protection domains, segments, capabilities and resource groups.

Problem
Private address space system is not very suitable cooperative application (where there is need to share pointer based information). Opal tries to solve the problem of tradeoffs between protection and performance persist with the conventional systems introducing single address space with efficient sharing data of data without losing the performance.

Contribution

A new protection scheme where all processes share the same address space. This allowed Opal to segregate addressing and protection. The main contributions are segments, protection domains and capabilities. Protection domain restricts threads executing in it to access only set of segments it is allowed to. Portals are introduces to transfer control from one protection domain to another. Capabilities are used to attach/detach the segments to thread's protection domain. Resources are managed using resource groups and are reclaimed back using reference count technique.

Evaluation
Evaluation is made on execution time of a tree-indexing program for three configurations(Monolithic, Decomposed and overlapping). It claims that overlapping protection performs equally well as monolithic while providing equally safe system as Decomposed.

Confusion
- It is still not very clear how protection domains are implemented under the hood to guarantee isolation.
- The one of the features of Opal embarks is that it can be made modular unlike conventional operating systems.
I would like to know more about how modularity helps when it comes to building OSs.

1.Summary
Opal is a single address space operating system which was built on a 64 bit architecture. The crucial design concept here is the separation of the addressing and protection which are bound in the “process” concept of systems such as Unix and Multics. As there was a single interpretation of any address, the sharing of data was done through sharing pointers.

2.Problem
Designing an application with highly interacting processes is a tradeoff between a performance and the protection in case of the conventional OS. If whole of data is placed in the same process, the protection is compromised and if the data is placed in separate processes, then the processes interact with each other through IPC’s which leads to poor performance.
Thus there is a need to come up with an approach with does not compromise protection of data while the sharing of data is faster and more efficient.

3. Contributions
The main idea here are single address space and separation of addressing and protection.
Protection domains gives the context of execution for the threads. Segments are the smallest unit of memory. Right to access a segment is determined by the capabilities of a protection domain in which the thread executes. Communications between the protection domains happens through portals which provides a point of entry to a domain. In this architecture the data is shared between the processes using the pointers which makes it makes than the IPC’s in the UNIX OS. Resource group makes sure that each application gets the fair share of their resources.

4. Evaluation
The Opal is implemented on top of Mach microkernel. The advantage of using the Opal in the CAD systems is described and evaluated and has concluded that the Opal best suits the requirement of CAD since it provides an efficient data sharing capability.

5. Confusions
->When there is a single address space why do they need virtual addresses?
->Why is this implementation not popular now?

1. Summary
This paper talks about opal, an experimental operating system designed to explore the strengths and weaknesses of the single-address-space approach. This model tries to achieve better performance in integrated software environments by completely separating addressing and protection. Protection in a shared address space is preserved using protection domains and capabilities for segments.

2. Problem
Operating systems providing private addresses are good for protection but perform poorly when sharing of data is required in applications using pointer rich data structures. As pointers have no meaning beyond the boundary of the process, data has to be copied between private virtual memories to allow sharing.

3. Contributions
The use of single address space for all applications was aimed at providing efficient sharing of data by eliminating the need of copying it. Protection was provided by allowing threads to run only in one protection domain and access only those pages which are present in the same protection domain. Virtual pages were divided into segments which could be attached/detached to protection domains.

Resource reclamation was handled with explicit reference counts and resource groups were used for bulk deleting of resources. Reference objects were used to prevent untrusted threads from releasing more counts than it requested by keeping a separate count for shared resources requested by each entity. Opal domains were allowed to create portals (to allow sharing) that permit other domain to call it in a protected and controlled manner.

4. Evaluation
Opal was implemented on top of Mach microkernel. To evaluate the performance, a simple mediator-based application was implemented and experiment was performed in three different protection configurations. The graph in figure 4 shows that the performance in overlapping protection domain configuration was almost similar to the performance in monolithic configuration which confirms the performance benefits of opal design.

5. Confusion
How exactly are capabilities used?
The concept of resource group and mediators is quite unclear to me.

1. Summary
The paper discusses reorganizing operating systems by revisiting some of the major design decisions in earlier operating systems about sharing and protection. This work is enabled by the availability of 64-bit address space architectures.

2. Problem
Multiple address spaces were used in systems with small address space architectures to provide the illusion of more memory to processes, and provide isolation between them. One of the major problems with the multiple address space approach was that there was no easy way to communicate with high performance among different processes. Security would be diminished by placing all parts of an application in a single process. But with the availability of large address space architectures, some of the hardware limitations that inspired the currently prevalent designs in operating systems can be revisited and improved upon.

3. Contributions
One of the major ideas from this paper is that addressing and protection are orthogonal and need not be tightly coupled. Communication between processes using shared memory is very much simplified in a single address space and provides high performance. The notion of protection domains is introduced to protect memory segments from unauthorized access even though they are addressable. Memory segments can be attached and detached when allowed allowing communication and code sharing. Virtual address space is treated as a system resource just like any physical resource managed by the OS, which should be managed fairly.

4. Evaluation
The Opal operating system was built over a Mach 3.0 microkernel. The Boeing CAD system was used as a representative of a class of applications in which number of software processes work together to solve complex tasks. The performance evaluation shows that much of the overhead was due to Mach primitives, and hence it does not provide a clear picture of actual performance due to key ideas in Opal.

5. Confusion
I did not clearly understand why portals are needed and how their checking works.

Summary
The paper described memory sharing and protection support in Opal, a single-address-space operating system designed for 64-bit architectures. As described in the paper, the goal of Opal is to enhance sharing, simplify integration, and to improve the reliability and performance of complex, cooperating applications manipulating large persistent data structures.

Problem
According to the authors, the mechanism for memory protection with private address spaces, isolating programs within private virtual address spaces, brings difficulties to efficient cooperation between protected processes.

At the same time, the arriving of wide-address (64-bit) machines made it possible to have a single-address-space operating system work for all the processes on a personal computer. Thus the authors started to explore the pros and cons of a single-address-space operating system comparing to the private address space ones.

Contributions
Portal.
According to the paper, “A portal is an entry point to a domain… Any thread that knows the value of a portalID can make a system call that transfers control into the domain associated with the portal.” Based on what I know; portal is a unique abstraction in Opal which can provide protection during the memory sharing.

Treating all virtual address space as a global resource controlled by the Operating System. Intuitively, this design would bring enhance performance but introduce risks by memory sharing. Opal introduced mechanisms like password capabilities etc. and provided convincing protection designs.

Evaluation
The paper explained Opal in detail, exploring the pros and cons of a single-address-space operating system. The evaluation methods and results within the paper are comprehensive and well supported the claim that single-addressed-space can work well. At the same time, I wish the explanation on the protection mechanism be more detailed thus easy to understand.

I also found the interesting claim from the authors that “Wide-address (64-bit) architectures facilitate the single-address-space approach by eliminating the need to reuse addresses… A full 64-bit address space will last for 500 years if allocated at the rate of one gigabyte per second”. Even the paper was written 13 years ago, 64-bit address covers very large memory spaces, probably even enough for PCs nowadays. This leads me to think why most modern OS still follows the private address design but not this single-address-space as this paper did pointed out many advantages of the single-address-space design.

Confusion
1. I wish they explain more about how capabilities work exactly?
2. Why are most modern systems that we use nowadays not following Opal but still follows private address space design? Is that because of compatibility?

Summary:
This paper describes the design of Opal, a single address space operating system built for wide-address architectures. This system provides efficient sharing, flexible protection, easy integration, thereby improving the performance of complex cooperating applications.
Problem:
> Isolating the programs within private virtual address space for memory protection highly restricts sharing of memory references. Sharing through files or messages hinders performance. As a result, application designer had to find tradeoff between protection and performance.
> Existing operating systems did not take advantage of the 64-bit address space architectures. Hence the authors felt there was scope to improve the organization of the existing operating system.
Contributions:
> The main contribution is the idea of full separation of addressing and protection.
> All the processes operate in a single address space which makes sharing much easier through memory reference and avoids the costly copy.
> Protection in a shared memory environment is obtained by having each thread execute in a protection domain, which limits its access to specific pages/segments.
> The protection domain can also dynamically attach and detach a segment or access any resource, given the named capability. A domain can set up portals to allow other domains to call it in a protected manner.
> Resource groups facilitate bulk deletion of unreclaimed resources and efficient accounting. Premature reclamation by malicious thread is also kept in check.
Evaluation
Opal prototype is implemented on top of Mach microkernel and its performance is evaluated by experimenting with integrated CAD environment. The performance is good because this application involves extensive data sharing and co-operating components. Experiments on tree-indexing programs shows that the configuration with overlapping domains clearly outperforms non overlapping domain configuration.
Confusion:
How different or more efficient is attaching a segment to protection domain compared to shared memory for IPC in Unix system ?

1. summary
This paper is about an operating system, Opal, designed around the idea of using only a single virtual address space instead of processes each having their own unique space.
2. Problem
The main problem that the Opal system tries to address is that with multiple address spaces cooperation between processes is overly complicated and inefficient. Cooperation generally requires copying data between address spaces which sacrifices performance or using processes with a shared address space with limits the protections between the processes.
3. Contributions
The Opal system introduces a complete system that makes use of a single address space for all processes while maintaining memory protections. It acknowledges the switch to a 64bit address space allows for the single address space without any real concerns of capacity limits. Memory is allocated in large contiguous segments each of which has a set of named capabilities that specify the actual permissions to the segment. A single process can have multiple segments associated with it and multiple processes can have access to each segment. This allows for very efficient sharing of all data between processes and allows for all pointers to be equally valid for any of the programs that might access the same data.
4. Evaluation
Their implementation they used to test their system involved creating an Opal server on top of a Mach microkernel to allow for faster development. Using this system they showed that an application that the performance of using a heavily shared database could be largely increased with a single address space as it could avoid a large amount of the communication overhead. Considering this is the main usage case they were hoping to improve it is a very good sign for their system but it would have also been nice to see a smaller scale comparison. Would the same improvements be seen with a comparatively small dataset and a smaller number of accessing processes?
5. Confusion
I am still uncertain on how exactly the permissions are enforced. In their system, they use the underlying Mach kernel to enforce the protections. Is some form of kernel running under the Opal system necessary to enforce the protections? We couldn’t think of how they might be enforced without the hardware support mechanisms currently provided for separate address spaces that didn’t require considerable overhead.

1. Summary
This paper presented Opal, a single-address space operating system. The main idea being that with the advent of 64 bit address space you can use the shared address space to save on performance without sacrificing the protections of using isolated segments by using protected domains.

2. Problem
Isolated processes are hard to communicate between costing either performance by using pipes or similar communication or isolation by combining into a single process. With 64 bit addressable space there is now plenty of memory for a shared system but security then needs to be handled differently.

3. Contributions
The main contribution of this paper is its description of how it created a single-address space to overcome the communication issues of isolated processes. The paper also backed up this new system with strong protection features by creating these protection domains that are the new way of isolating data. Opal achieves this protection by granting and restricting access to certain address segments. The paper also treats child domains as untrustworthy so as to protect the parent domain and allow untrustworthy programs to execute.

4. Evaluation
The paper spent a large portion descri9bing its evaluation system which included building on top of an existing Mach microkernel and using CAD tools from Boeing. The CAD tools are a good example of the best usage of Opal because the tools usually have to work together but could be run by separate users so they must have protection built in. I personally really liked that they used such a good real world example to show off their operating system.

5. Confusion
Some of the points on how protection domains were implemented was unclear, specifically who grants and monitors the accesses to the segments. Also how does the system determine a good value for the size of segments at allocation.

1. Summary
This paper introduces a single address space operating system called Opal designed for 64-bit architecture. It provides better memory sharing between processes while at the same time maintain good protection.

2. Problems
The 64-bit architecture greatly expands the address space, this leads to the problem about how can we make use of this address space that is big enough to hold multiple processes. Also, traditional process protection mechanism makes it hard to share pointer based data since pointers are related to the private address space. Placing everything in one process sacrifice the protection, while sharing data through ipc leads to poor performance, this is the problem of the tradeoff between performance and protection.

3. Contributions
The key contribution of this paper is to separate protection and addressing in a single address space. To provide protection, this paper introduces protection domain which limits the thread execution into many segments (basic unit of memory management), and uses capability to identify the legal access to a memory segment. With single address space, the Opal system removes the complicated page table structure and simplifies the switches between processes, which leads to better performance. Communication between processes also becomes easier using direct communication inside protection domain or portals between domains. Information sharing between process can now uses pointers directly, instead of using serialized message through file or pipes, this can be very effective in some complicated software systems like CAD.

4. Evaluation
This paper demonstrates the performance of Opal in a CAD database system of Boeing. This is a special kind of application very suitable for Opal since there is a great need of data sharing among different components storing pointer-rich structures to disk. The performance is good in this experiment, but I think maybe the author should do some more experiments in different environments, like general computing environments.

5. Confusion
In section2.2, this paper mentioned a distributed single address system where there are multiple nodes connected through network, I don’t understand what is single address space in this environment.

Summary

Paper explores memory management in Opal, a single 64 bit
address-space operating system. The motivation for Opal-was
performance.Since Opal is a single address space system, it needs
different modules and mechanisms to deal with memory and
protection. Memory management and hence process protection seem to be
the main theme of the paper.

Problem

1) Interprocess communication is just too inefficient with virual
address spaces. The best way to communicate large chunks of data is to
pass pointers.

2) There is always a tradeoff between performance and protetion. In
the authors opinion, the OS's of then focused too heavily on
protection. He claimed opal provided a better balance.

Contribution

1) Opal uses single virtual address space for all procedures and
process, so the two process(threads) can efficiently communicate with
each other using shared memory.

2) Opal treats addressing and protection as separate problems. With
their single address space setup they can directly share pointers
without complex handling of memory. They can also reduce loss due to
cache flushing, TLB's on context switches. The OS handles protection
separately now. It no logner contains free as it did with isolated
processes.

3) They use mediators for runtime support and event manager but this
section seemed vague and I couldn't tell what they were doing
completely

Evaluation

I have never worked with a single address OS. I am not sure if the
system is as secure as they claim to be. Programs are granted access
to a shared segment are trusted to use it correctly and user code is
responsible for using the available mechanism to protect itself from
damaged caused by failures of untrusted threads

There seems to be too much trust of application code and that is
always a dangerous avenue.

They do mention there is a tradeoff between performance and security,
but in my opinion a high performing insecure machine is useless but a
low performing secure machine is still usable.

What about fragmentation. Seems like there is a serious risk of
fragmentation

Confusion

Security! It's never clear to me how these things work, till someone
draws a picture on a whiteboard.

How does the kernel exactly keep processes isolated? Does each process
have a table of start and end segments in memory?

1. Summary
The paper talks about memory sharing and protection in Opal - single address-space OS designed for wide-address architectures. Addresses are context-independent and protection domains manage access rights for different segments.

2. Problem
Conventional OSs have different virtual address spaces for each process that leads to poor tradeoffs in performance and protection. Different processes communicate via IPC and shared memory which thereby hurts the performance. Likewise, applications cannot include all components in one process as this would sacrifice protection. With the advent of 64-bit address space machines, the amount of address space available to OS increased dramatically, allowing explorations with wide address spaces. This also meant that all the processes could now use the same address space.

3. Contributions
The novel realization from the paper is that addressing and access are orthogonal. By defining single address space, addresses are now context-independent. Protection domains restrict access to different memory segments. Opal threads execute within protection domain in single address space. This increases flexibility as applications can now directly share procedures and pointer-based information. To facilitate communication between domains, the paper introduces the notion of portal. Portal is simply an entry point for a domain. Another significant contribution is that the paper also talks about issues in dealing with single address-space OS.

4. Evaluation
Opal is evaluated for performance on CAD system from Boeing that has lot of pointer-rich data structures. The needs of industry-grade application are well studied wherein lots of applications access a shared database. One of the main things to note is that Opal is emulated by implementation single address-space design on an existing microkernel. Thus, Opal is comparable in performance to existing systems.

5. Confusion
I am not very clear about how protection domain, portal and segment access would work in a distributed cluster.
The paper talks about specific use case of CAD system of Boeing. What other applications can one think of wherein Opal might/might not perform better ?

1. Summary
This paper presents Opal, a single address space operating system designed for 64-bit architecture. Opal provides flexible sharing among processes (such as sharing pointer) while guaranteeing security by running all threads in the same virtual address space and decoupling addressing and protection using new features including protection domains, capabilities and resource groups. The Opal prototype is implemented as a server on Mach kernel and is evaluated using Boeing CAD software.
2. Problem
In conventional private-address-space operating systems, processes run in different virtual address spaces, forcing hard memory protection boundaries, but they are not flexible in terms of inter-process cooperation and sharing especially for pointer rich applications. Or programmers can put all components in one process and use multiple threads, which sacrifices security.
3. Contributions
Authors believed that 64-bit architecture could provide enough address space to hold all processes in one virtual address space and thus treats virtual address space as a global resource. To provide isolation, Opal defines protection domain, which is a thread execution environment with restricted resource access permission. Access permission is represented as capabilities. By gaining memory segment capability, a thread can attach the memory segment into the domain allowing all threads in the domain the access the segment. By gaining domain capability (which contains portalID of a domain), a thread can transfer control into another domain through which Opal does cross-domain RPC. Resource management is done with the concept of resource group, which forms a tree-style resource ownership representation and is managed through reference counting.
Authors implement Opal prototype on Mach microkernel which proves that single address space environment could be implemented on a microkernel and coexist with other conventional operating systems such as Unix.
4. Evaluation
Opal is evaluated with a Boeing CAD software, which has a large pointer rich shared database and large number of running threads. Experiments on a tree-indexing program proves that Overlapping (Opal) performs similarly to Monolithic (emulating one Unix process with multiple threads) and greatly outperforms Decomposed (emulating multiple Unix process). Authors also presented the execution time of some Opal operations, demonstrating the overhead of implementing Opal on a microkernel
5. Confusion
How are capabilities stored, shared and accessed in the shared memory? They are key elements to insure isolation in a single address space, but how are they protected against illegal and malicious accesses?
What is the exact procedure of doing a cross domain RPC and how is portal used?

Summary:
The paper presents Opal, a single-address-space operating system, built to eliminate the trade off between protection and performance forced by private address space systems. Opal design is based on the hypothesis that wide-address architectures eliminates the need to reuse addresses which is required on 32-bit architectures.

Problem:
Conventional multiple address space operating systems present a trade off between protection and performance. In these systems, memory protection is ensured by isolating programs within their private virtual address spaces. This isolation mechanism makes cooperation between application components in independent processes inefficient because the data is shared through slow mediums such as pipes or messages. On the other hand, keeping all the components in one process compromises protection. Opal is an attempt to solve this problem by keeping all the processes in single global address space and decoupling protection from the “process” concept of systems.

Contributions:
Opal uses single address space. Protection is separate from addressing. Hence two processes can easily communicate using shared memory.
Storage allocation and protection is handled at the unit of segments which are contiguous extent of virtual pages. Threads execute in protection domain which restricts their access to a specific set of segments. A thread can request to attach a segment to a domain, given it knows the proper capability. Control transfer from one domain to another is permitted through portals. Resource reclamation is handled by explicit reference counting backed by resource groups.

Evaluation:
The authors implemented an Opal prototype on top of the Mach microkernel and evaluated a tree indexing program running in three different protection configurations. The program consists of producer, consumer and a mediator process. They demonstrate that the configuration with overlapping protection domain provides as much performance as the configuration with shared protection domain; while also providing better protection than shared protection domain configuration. Both these configurations perform better than separate protection domain configuration which is similar to executing three unix processes.

Confusion:
Where is the information stored about which thread has permission to access which segment?
How are the capabilities used to ensure protection?

Summary
This paper demonstrates that storage allocation, protection and reclaimation at the language and runtime level are better than those at the operating system level (Unix). Based on this philosophy, the authors design Opal, an OS with a single virtual-address space with separated memory addressing and protection. Such a system provides convenience and flexibility for memory sharing.

Problem
Current systems give each process a private virtual address space. Although protection is gauranteed, this private address space is inconvenient when two processes need to cooperate on certain piece of memory. Memory sharing needs to compromise protection. Therefore modularity of memory in OS level (process) is not optimal.

Contribution
The single-address-space system Opal makes significant changes on the traditional unix systems. It cancels the concept of processes, makes all programs running in threads. The memory is grained in segments and can be dynamically shared by threads. With these modifications, the Opal system reduces the overhead in the memory sharing between to tasks much and make it flexible to share memory.

Evaluation
The authors evaluates Opal in an integrated environment. It shows that mediators on Opal can achieve nearly the same efficiency as monolithic unix process by using the overlapping scheme. The authors also evaluate the Opal system on a Digital Alpha processor. The single-address-space Opal is build on the top of Mach microkernel. The authors measures the time consumption of Opal's operations and compare it with their counterpart in Unix. The results is all Opal's operations are competitive to those of Unix. However, the this paper does not have memory consumption comparison results.

Confusion
1. Why are we still using Unix-based systems like Linux and Mac Os instead of Opal?
2. The authors mention 64-bit machines several times. What does 64-bit matter?

Summary
This paper introduces an operating system “Opal” which uses a single virtual address space in 64-bit machine to enable efficient, safe data sharing between several applications with flexible protection domain to ensure the protection.

Problem
The primary problem is that we used to separate different processes to implement protection mechanism, but the communication between processes become expensive this way. Now we have 64-bit address space, it is quite large compared with the actual physical address space. How do we make use of this feature to enable a more efficient and safe way to enforce the communication and data-sharing.

Contributions
It presents a way that all the processes share the same address space while keeping the addressing and protection separated, so that it has multiple protection domain. A protection domain is an execution context for threads and it restrict the access rights of the threads. Moreover, Opal requires no address translation anymore and is capable of passing pointer between process to share memory which makes Opal way more attractive.
Taking advantage of the idea of single address space, we can reduce the complexity of hardware, simplifying the hardware architecture and better the performance.
The author also presents the idea to extends it to workstation or even a small network.

Evaluation
The author did a comparison on application level with Unix kernel. This particular application is the ones the author wants to enhance because it certifies the features he mentioned at the beginning, manipulating large persistent data structures.

Confusion
Solution to deal with external fragmentation is unclear. This address space is much larger than a process-level heap.

Summary
This paper demonstrates that storage allocation, protection and reclaimation at the language and runtime level are better than those at the operating system level (Unix). Based on this philosophy, the authors design Opal, an OS with a single virtual-address space with separated memory addressing and protection. Such a system provides convenience and flexibility for memory sharing.

Problem
Current systems give each process a private virtual address space. Although protection is gauranteed, this private address space is inconvenient when two processes need to cooperate on certain piece of memory. Memory sharing needs to compromise protection. Therefore modularity of memory in OS level (process) is not optimal.

Contribution
The single-address-space system Opal makes significant changes on the traditional unix systems. It cancels the concept of processes, makes all programs running in threads. The memory is grained in segments and can be dynamically shared by threads. With these modifications, the Opal system reduces the overhead in the memory sharing between to tasks much and make it flexible to share memory.

Evaluation
The authors evaluates Opal in an integrated environment. It shows that mediators on Opal can achieve nearly the same efficiency as monolithic unix process by using the overlapping scheme. The authors also evaluate the Opal system on a Digital Alpha processor. The single-address-space Opal is build on the top of Mach microkernel. The authors measures the time consumption of Opal's operations and compare it with their counterpart in Unix. The results is all Opal's operations are competitive to those of Unix. However, the this paper does not have memory consumption comparison results.

Confusion
1. Why are we still using Unix-based systems like Linux and Mac Os instead of Opal?
2. The authors mention 64-bit machines several times. What does 64-bit matter?

1. summary
This paper describes the design and implementation of an operating system called OPAL that is based on a single address space architecture. The fundamental design philosophy behind this operating system is to decouple protection and addressing in an operating system and this paper discusses the techniques and the consequent trade-offs towards achieving that goal.

2. Problem

In the multi-address-space systems that are in universal usage protection and addressing are closely tied. This approach inherently makes data sharing difficult. Pointer based sharing in particular is cumbersome as pointers have no meaning beyond the lifetime of a program.

3. Contributions

The advent of 64bit address schemes provided an opportunity to solve the above problem by having a very large single address space such that a given address always points to the same data. OPAL divides the address space into virtual segments and a protection domain can only have access to the segments to which it is attached. The address of a segment is a permanent attribute which makes sharing memory sharing between protection domains much easier. The unit of execution in OPAL is a thread which executes in the context of a protection domain. In addition OPAL has a Portal abstraction which is associated with the protection domains. Portals are used by domains to allow memory sharing.

4. Evaluation

The authors evaluate the OPAL prototype on the Boeng CAD system and show improvement in execution times.

5. Confusion

I did not quite understand how are capabilities operating and why are they needed.

1. Summary
This paper introduces single-address-space operating system, with the goal of better interaction and sharing between software components. The key idea is a single virtual address space for all computation.

2. Problem
The problem arises from the unsatisfactory performance of sharing, storing or transmitting pointer-based information e.g. in database application. In traditional private-address-space architecture, such virtual-address-related (pointer-based) information has to be translated into intermediate representation before transmission or persistence. In addition, private-address-space systems force poor tradeoffs between protection, performance and integration. E.g., sharing information between processes through pipes, files, or messages sacrifices performance, while maintaining protection. Placing all components in one process gain performance without protection. In addition, sharing pointer-based information in shared memory of private-address-space is hard to implement. Forcing all processes map the shared memory into same virtual address is ad hoc.

3. Contributions
The main contribution of this paper is designing a model for single-address-space OS, and implementing a prototype for a database application to demonstrate its efficiency.

In single-address-space OS, unit of memory management is segment, which is one or more contiguous pages. The traditional process concept in private-address-space is separated into thread and protection domain. Thread is unit of execution, and protection domain determines which segments the threads can access. As the authors mentioned, a global hashed page directory can be used, instead of page-directory-per-domain. The global page directory can perform better when doing context switch between threads across different protection domains, because there's no need to switch page directories. The access control is enforced as capability. A capability is a 256-bit reference that confers permission to operate on an object. To add/remove new segments for one thread, capability is used to attach/detach the segment to thread's protection domain. Threads in same protection domain communicate with each other directly. Threads in different protection domain can communicate through portal. A portal is an entry point exposed by one domain to another. This is much safer than traditional shared memory because all communication is conducted in a protected and controlled manner. Segments is managed by reference count, and threads are divided into resource groups. Recourse group is responsible for segment management. However, reference count can still cause dangling pointer problem as author mentioned, it pushes the responsibility to users to take care of their own code.

4. Evaluation
This paper implemented a prototype Opal, which built the single-address-space OS on top of a microkernel OS (Mach). To demonstrate its performance, it compares with Unix kernel for an Boeing CAD system database application. The database application is suitable for demonstration because it needs data sharing among software components heavily and needs support to directly store pointer-based information into database. The result shows Opal's performance is acceptable, while the authors mentioned the performance is partially influenced due to building upon Mach.

5. Confusion
I don't understand how password capabilities work exactly. It seems that how capability works have big impact on system performance, because access control check may be a frequent operation when thread accesses memory.

1. Summary
The authors present an implementation for a Single-Address-Space operating system called Opal. They provide a survey of techniques and previous designs that inspired them to develop it. In this paper they focus on how allocation and protection of shared memory segments between process. They show that they can build such an OS as extensions to a commodity system such as their use of the Mach 3.0 microkernel.
2. Problem
Understanding/Experimenting with single address space approach to an OS.
Another goal is to demonstrate that such a system can built using commodity hardware and software (by avoiding specially built hardware, or requiring the use of special language features).
3. Contributions
- Opal OS a shared address space OS and experimentation testbed
- A survey of previous efforts for developing single address space operating system.
- The analysis and design of a decoupled approach to memory allocation and protection.
- An analysis for how manage a single address space using coarse grained controls over both protection and allocation of memory (opal mediators)
4. Evaluation
The paper spends a considerable time evaluating the system with a representative of a particular class of applications(Integrated development environments) using the Boeing CAD system. They show how the opal mediator mechanism leads to improved execution time performance as in figure 4.
They further spend some time comparing overheads of their approach and how they can be improved and how much of those are caused by the underlying mach microkernel.
Another effort is put into highlighting the issues/ negative effects of a single address space approach to such a design. Overall a balanced review and analysis of the technique is provided
5. Confusion
I feel they should have spent some time motivating the use for the decoupled allocation and protection of memory for a general purpose os where we can have applications that don't use shared memory as much as the applications and use case scenarios suggested by the authors.

1. Summary
The Opal OS implements a single shared virtual address space, allowing for simple sharing of memory between processes. It decouples addressing and protection through its abstractions of capabilities for access control and protection domains as execution contexts. This allows different processes to share memory easily without compromising on protection. Opal is built on top of the Mach microkernel and sits between the microkernel and system processes.

2. Problem
Conventional operating systems with their model of private address spaces for processes force poor tradeoffs between performance and protection for applications such as CAD, CASE etc. seeking to share pointer-rich data between its components. They can either run components in different processes that communicate through pipes or sockets, thereby sacrificing performance or place all components in one process sacrificing isolation. With the advent of 64-bit addressing on RISC processors, the authors argue that these applications can be better served by a single-address-space structure, with other abstractions to provide similar protection to private address space-based protection.

3. Contributions
The single-address-space idea is not new and has been explored in previous capability-based and object-based operating systems. However, the novelty of the paper's contribution lies in achieving this goal without needing special-purpose hardware, or a single type-safe language. With this single address-space idea, processes can exchange data by simply sharing pointers since they have fixed addresses.

It is also able to achieve the goal without loss in protection by decoupling it from addressing through various abstractions such as segments, protection domains and capabilities. “Segments" are contiguous sections of virtual pages that can be attached / detached from "protection domains" which act as thread execution contexts. Opal defines “capabilities" for these resources to provide access control. Opal is thus able to provide the same level of protection as the process-based protection of private address-space operating systems.

4. Evaluation
The authors evaluate an example application consisting of processes sharing pointer-rich data. It consists of producer and consumer tools, where the consumer maintains different indices to the same underlying data generated by the producer. From their results, they demonstrate that “overlapping” protection domains are almost as fast as the monolithic domain case (equivalent of running everything in one Unix process). This is in line with their original goal of providing high-performance shared memory without compromising on any of the protections provided by private address space OSes.

5. Confusion
1. I didn’t quite understand how the mediator framework is helpful. The paper says it it factors out the knowledge of the dependencies from the tools. Can an example be provided for this?
2. Is the mediator framework actually able to achieve the earlier stated goal of updating the derived objects incrementally? How does that work?

1. Summary
Opal is a research OS where all processes and data share the same address space. Unlike in a conventional OS, memory protection and addressing are dealt with as completely orthogonal concerns.

2. Problem
Conventional OSs combine protection and addressing by giving each process its own isolated address space. While this abstraction has worked well in the past, it makes sharing data between processes and changing the method of protection very difficult. Additionally, machines were moving to 64b addresses, greatly expanding the size of the available address space. What should we do with all that extra space?

3. Contributions
By building a working prototype, Opal shows that it is possible to build a single address space operating system with a completely separate protection scheme provided by the kernel. Because they are isolated pieces of the system, both the memory protection scheme and resource allocation mechanisms can be easily altered, upgraded, and experimented with. In conventional OSs, the private address spaces of a process make it much more difficult to play around with different protection schemes.
The authors also write a linker that shows that conventional executables can be run in a single address space operating system without recompilation or other major change. This is a major difference from the Singularity OS; Opal is made to provide a single address space OS with as little change for running applications as possible.
Another contribution the authors make is section 6, clearly highlighting the problems with a single address space OS. Having these problems so clearly outlined is a great tool for future researchers to know the issues they should tackle.

4. Evaluation
Opal is evaluated by emulating the single-address space system on top of an already existing microkernel. Their main performance test is on a CAD toolset from Boeing. The performance issue they target is a large shared database that is causing huge bottlenecks on their current system. This application is the perfect fit for Opal: it features a large amount of shared data being operated on by a variety of tools that run as separate processes. The authors make a similar argument to Singularity concerning protection domains, comparing Opal’s performance against a itself while making the settings more restrictive (Fig 4). However, they go on to compare the latency of similar operations in Unix and on their prototype, with some encouraging results (section 5.3). Although Opal has some overheads, they are not astronomically high, even on this untuned prototype version.

5. Confusion
I did not understand how exactly the capability mechanism works. It sounds pretty insecure to me.