CS 736 Reviews - Spring 2016

1. Summary
This paper proposes a new OS structure for multi-core systems, the multikernel, that treats the machine as a network of independent cores with replicated state that communicate via message passing. This is in contrast to the prevailing shared-memory based structure. Learnings from distributed systems and networking can be leveraged in this new pardigm. The paper also discusses the motivation, design principles, implementation (Barrelfish), and evaluation via performance metrics.

2. Problem
• Current OS structure is tuned for a coherent shared memory with a limited number of homogeneous processors, and is poorly suited for adapting to the diversity and scale of future hardware.
• In commodity general purpose systems, the number of processor cores is growing, which in conjunction with the increasingly diverse mixes of cores, caches, interconnects leads to scalability, longevity, and optimization challenges.
• These challenges are mostly due to the structure - a shared memory kernel with lock-protected data structures.

3. Contribution
Primary contribution : The conceptualization of the OS as a distributed system of functional units (with OS instances) communicating via explicit messages - the multikernel model.
• Message based communication - enables networking optimizations such as pipelining and batching, and allows easier analysis.
• Global OS replicated across cores - helps scalability, and extensibility to peripherals and domains that do not share memory.
• Hardware-neutrality + provides a way to deal with cores with heterogeneous ISAs.
• The modularity of the OS can be exploited for intelligent resource management and job scheduling utilising the inter-core topology and other hardware knowledge. Learnable at run-time via a service known as the System Knowledge Base (same authors, prior publication).
• Barrelfish is factored into privileged-mode CPU drivers that are local to cores and perform low-level tasks, and user-mode monitors that encapsulate mechanism and policy and run an agreement protocol for consistency.

4. Evaluation

Notes:
• OS structure is hardware-neutral which disallows platform-specific trade-offs and optimization in the OS, but increases longevity, compatibility and scalability.
• Porting applications to this system should be fairly straight-forward.
• The OS programming style will formally move to the event-driven model. Application programs can continue to operate in the shared memory paradigm.
Benchmarks:
• Both large scale benchmarks and micro-benchmarks have been evaluated.
• TLB shootdown - Barrelfish - Multicasting (allows parallelization) using SKB ennabed routing scales better than Windows/Linux using IPI.
• Two Phase Commit and IP Loopback - Barrelfish outperforms Windows/Linux.
• Various Compute workloads - comparable performance.
• I/O workloads - comparable or Barrelfish better.

5. Confusion
Dispatchers, SKB's working / location.

1. Summary
The paper describes Opal which provides a single global virtual address space that is shared between all procedures and the data as opposed to systems like Unix with private address space for every process. The paper discusses the sharing and protection mechanisms to support a single address space OS where different modules can share data efficiently across thread boundaries without compromising on protection by being bound to the same process.

2. Problem
64-bit architectures provides a huge virtual address space which no longer has the limitation of reusing of addresses required by 32-bit architectures. This means that there is no longer a pressing need to have private address space for each process and we can have a global address space shared by applications and still have enough address space for individual applications in this shared space. Having a global address space makes sharing easier - applications no longer have to write to a file or use pipes to exchange data. A complex data structure with pointers can be shared between applications without the need of serialization/deserialization, providing huge performance benefits. At the same time protection need not be compromised, by keeping untrustworthy modules that share data in the same process boundary just to make sharing efficient.

3. Contributions
The main contribution is providing various mechanisms and abstractions (concepts reused from previous systems) as to enable a single address space OS. They provide a way of context-independent virtual addresses by providing segments as units of storage allocation and making the virtual address of a segment a permanent attribute and making it easier to share the data. Another main contribution is the separation of protection and addressing. Protection is no longer provided by having private address space. In Opal threads are units of execution and each thread has access to a collection of segments in a protection domain. Multiple threads execute in the same protection domain. The system uses capabilities to control access to segments. Sharing across domains is done through portals, where clients with capabilities can make RPC calls to servers to share data. In a private address space system, garbage collection is simpler as everything can be reclaimed when a program exists.
The paper provides an effective way of reclaiming address spaces by using explicit reference counting during Attach and Detach of segments and resource groups to bulk delete of unreclaimed resources.

4. Evaluation
The authors evaluate the Opal Prototype built on top of Mach Microkernel. The authors have evaluated how their system while providing the same safety guarantee provided by having non overlapping domains communicating via RPC perform better than such an architecture. The authors have also shown that system provides the same performance benefits of a monolithic approach of having the modules in the same process while providing better protection. This was the core of the paper - separation of addressing and protection and I think they have evaluated that well.

5. Confusion
Is the operating system outside of this global address space? How is synchronization handled for these shared address space? Why did modern OS not adopt the concept of a single-address space?

1. summary
The paper describes Opal, a single global virtual address space system.
As opposed to traditional private virtual address spaces. The authors postulate that this has the potential to greatly ease memory/data sharing without the loss of protection. The paper discusses the philosophy, motivation, abstractions, prototyping, performance and issues with this system.

2. Problem
At the time of writing of the paper, there was an emerging important class of integrated software environment applications that were composed of programs cooperating through a shared pointer-rich database (e.g. engineering design tools - CAD). The then prevalent 32-bit systems achieved cooperation and sharing primarily through copying data between private memories, which was not optimal. Also, with the advent of 64-bit bit architectures, there was at that time no longer a pressing need for re-using virtual addresses, as opposed to 32-bit architectures. Driven by these developments, the authors believed that there was scope for improvement in sharing without loss of protection.

3. Contributions
Primary contribution - Single address space - idea. The necessary abstractions and mechanisms for such a system.
Explores / discusses what is the right level of coupling / decoupling of various concepts throughout the paper.
Protection is decoupled from program execution (via RPC), resource naming (via capabilities), resource ownership (resource groups), virtual storage. All the above are strongly coupled in the traditional concept of a process.
Enables structuring of user software as a group of co-operating domains, with arbitrary sharing patterns.
Abstractions - segments (memory), capabilities (naming), threads (execution), protection domains (protection).
Mechanisms for Inter-domain communication, linking and resource management and reclamation in this system are discussed.

4. Evaluation
Opal was prototyped on the Mach 3.0 microkernel, details of which suggest that bidirectional interaction between opal and existing applications should be possible.
Issues:
Virtual Contiguity - segments cannot grow.
Address Space Conservation - one underlying belief is that there will rarely, if ever, be a need to re-use virtual addresses, given that it is a 64 bit system.
Unix -
Unix can co-exist with Opal above a general purpose micro-kernel, but Unix could not be built on top of a native Opal kernel, due to the idiosyncrasies of the fork command. That said, most Unix programs are capable of running in a single virtual address space.
Copy on write is more complicated in Opal.
Practical Measurement:
To evaluate performance, Boeing's CAD system was implemented on top of Opal, and measurements were taken of the Opal Overlapping domains model, compared to the emulation of a single Unix process and cooperating Unix processes on the same system. The results of the emulation suggest that Opal can provide the speed of the single monolithic Unix process model, without the associated loss of separation and protection.

5. Confusion
Storage allocation, protection, reclamation - what is the right granularity?
Password capabilities.
Protection Domains - child domain used to amplify parent's rights, 'privileged server must create child on behalf of the nominal parent' - unclear.

1. Summary

This paper discuss the design and implementation of Opal, a single address space operating system designed for 64-bit architectures. Opal simplifies sharing of code and data between processes while at the same time, providing protection. This paper puts forth the different abstractions that Opal uses to achieve this.

2. Problem

Mechanisms like pipes, temp files or messages do offer a safe way for transmission of data but are lacking in performance. Traditional systems sacrifice performance for this protection. The other extreme alternative is to sacrifice address space isolation completely, but that would remove any sense of protection between the processes. Opal tries to find the middle ground by combining different mechanisms and by seperating the notion of protection and addressing (sharing) while still not impacting performance.

3. Contributions

As stated above, one of the most important contributions of Opal was to seperate the notion of protection and addressing; the idea that they don't necessarily depend on each other.

The next significant contribution of Opal are its abstractions. The paper talks about the concept of a protection domain, which is simply an execution context for a group of threads. This domain has access to only a particular set of segments (unit of storage). And by being in the same domain, threads can share components in a simple way. This vastly reduces the communication overhead for different threads that need to share data (Related, and hence more prone to share data?). And in addition to sharing memory within a single domain, Opal, using portals allows for inter-domain communication (by overlapping segments). And Since all references are global, it presents an interesting opportunity to make the address space pan networks.

The paper also discusses the time stats for different Opal operations like segment and domain creation, but since these numbers may be impacted by the underlying microkernel (since all Opal abstractions were implemented in Mach), there is not a lot to take away from here.

The authors also show that Opal is as fast as a monolithic kernel while at the same time providing protection. However, there is no comparison to other private address space systems.

5. Confusion

How are shared segment accesses synchronized?

The authors propose a more coarse-grained OS in terms of resource handling and leaving the fine-management to higher-level applications. I would like to know what motivated them to think so.

1. Summary
The paper describes Opal, a single-address-space operating system designed for 64-bit architectures. The key idea of their design is to completely decouple protection from other concepts of an operating system, which are typically bound together in conventional systems that use private virtual space approaches, to reduce complexity and trade-offs between performance and protection in applications and software systems that heavily share data and code across domains. Pointers have no useful meaning beyond the scope of
2. Problem
The private address space approach has the advantage of providing a sufficiently large address space for each process, and providing protection when different processes reside in different address spaces. This separation, however, brings inefficiency when applications need to share data or want to set up and make RPC calls. Pointers are not usable beyond the scope of the process that creates them; system calls (like UNIX’s mmap) have to be made to allow memory to be shared across different processes, which brings expensive cost for applications that need frequent communication among processes on the same or different machines. Opal solves the performance problem by using a global virtual address space, while providing protection no less than private virtual address space approach with the design of protection mechanism decoupled from addressing, program execution, resource ownership, and resource naming.
3. Contributions
A very important contribution of this paper is the operating system’s design with a collection of abstractions that decouples protection from other concepts, thereby avoiding trade-offs between performance and protection when data is shared:

For storage and protection, Opal’s memory management is coarse-grained in a unit of Segment, whose size might be one or more pages. The access control to the segments is specified by the protection domain of the unit of execution, thread. Segments can be attached to or detached from a thread given a segment capability, which can be shared freely when the creator of the segment publishes a capability specifying permission of the capability along with the Access Control List that allows the thread to request it. Capabilities can be used to identify various data and service resources and shared globally, providing unified resource naming decoupled from the protection mechanism.

In execution, Opal shares the ability to make RPC calls through the creation of portals, which controls the code to be run within the protection domain. The portal can be identified by a 64-bit portalID which is included in a capability as well, therefore program execution is also decoupled from protection.

To provide resource ownership mechanism decoupled from protection and provide easy cleanup, resource ownership is assigned to each thread, and links to that of its children. This allows the system to do accounting on the usage of resource for a given thread.
4. Evaluation
The paper evaluates the performance of Opal by giving an example of building a CAD tool for Boeing Company on top of the Opal system, which has a high demand of data communication among massive nodes. The resulting application achieved competitive performance with other operating systems such as Unix, with similar level of safety and better code structuring.

Given the performance result of their experiment, I feel that the runtime support required for this system is a bit too heavy, though, which may make it inappropriate in some environments. In some hardware environment where resource is more restrained and when processes do not need much communication among each other, the runtime cost in memory and execution time can be significant and damaging, when processes generate and carry capabilities around.
5. Confusion
How does reference object remain unique for each thread? If it is named by a capability, shouldn’t capability be modified (instead of copied) before it is shared with others, since every thread should have separate reference object?

Summary:
Opal operating system a single address space operating system such that addresses have unique interpretation for all application at all times. The paper aims to enhance sharing without impacting protection , essentially decoupling addressing and protection.

Problem:
The primary sharing mechanism in systems with private address spaces relies on copying data between private virtual memories. This is inconvenient for large and sparsely used data structures. Use of single address space greatly simplifies this sharing as now virtual addresses are unique and persistent and can be shared directly.

Contributions:
a) Sharing is greatly simplified and will be much faster because context independent addressing. The idea of extending this to networked computers and clusters and having unique virtual addresses across systems can make communication and sharing a lot simpler.
b) The paper describes in detail how protection would be handled in these systems .
Protection domains, which are independent of addressing determine the context in which a thread executes and its access rights to memory segments. Segments are dynamically created and shared through capabilities.
However, a detailed analysis of this domain in different user scenarios will give more clarity to the readers.
c) Linking and executing code in the single address space system is space efficient.
d) Resource Management and Reclamation introduces new concepts of resource groups and resource objects which track the 'Attach' and 'Detach' and delete segments on last detach

Evaluation:
The Opal System targets applications which require integrated software environments such as engineering design that are inherently interdependent , share data structures and have rich interactions. It has been hence evaluated on the Boeing Cad System. The evaluation showed that:

a) Ease of communication comes at the expense of independence. Mediators to take care of inter-tool dependence separately. The Opal application built using mediators is configured to emulate different protection configurations show following results:
i) Performance is better in cases where tools either completely share a protection domain (same as one single Unix process) and when there are 3 different opal domains (same as Opal system)
ii) Performance is bad when domains are completely decomposed and message is passed using RPC(simulating different Unix processes)
This form of analysis is very abstract to measure performance as we are emulating just the scenario not the system calls and step by step process of what would happen.

b) Despite the use of reference counts, there can be cases where programs do erroneous pointer references. This has to be completely taken care by the user. I see this as a problem because as the size of the application grows there can be cases where user creates dangling pointers accidently. This system can cause the code to behave unpredictably and make debugging very difficult because we will be sharing data pointers across the system .
In private virtual address space systems pointers have no meaning beyond that specific process hence keeping the problem of dangling pointers localized.

c) The concepts :
1)Resource Groups - which tracks the resource and segments which thread accesses and
2)Resource Objects-which separate the counts associated with a thread for resource emanating from different entities basically to prevent untrusted threads from deleting useful information
Is a lot of information logging and will lead to huge memory being occupied by the OS itself.

Confusion

Why is copy-on-write not possible in single address space system ? A protection domain can create its own copy of data if it wants to write it by giving it a new virtual address in its own domain and inturn a new physical address.
Was this system adopted commercially at any point in time?
if not, What are major disadvantages of using this system other than virtual contiguity and conserving address space?

Sharing and Protection in Single Address Operating System

Summary:
Opal operating system a single address space operating system such that addresses have unique interpretation for all application at all times. The paper aims to enhance sharing without impacting protection , essentially decoupling addressing and protection.

Problem:
The primary sharing mechanism in systems with private address spaces relies on copying data between private virtual memories. This is inconvenient for large and sparsely used data structures. Use of single address space greatly simplifies this sharing as now virtual addresses are unique and persistent and can be shared directly.

Contributions:
a) Sharing is greatly simplified and will be much faster because context independent addressing. The idea of extending this to networked computers and clusters and having unique virtual addresses across systems can make communication and sharing a lot simpler.
b) The paper describes in detail how protection would be handled in these systems .
Protection domains, which are independent of addressing determine the context in which a thread executes and its access rights to memory segments. Segments are dynamically created and shared through capabilities.
However, a detailed analysis of this domain in different user scenarios will give more clarity to the readers.
c) Linking and executing code in the single address space system is space efficient.
d) Resource Management and Reclamation introduces new concepts of resource groups and resource objects which track the 'Attach' and 'Detach' and delete segments on last detach

Evaluation:
The Opal System targets applications which require integrated software environments such as engineering design that are inherently interdependent , share data structures and have rich interactions. It has been hence evaluated on the Boeing Cad System. The evaluation showed that:

a) Ease of communication comes at the expense of independence. Mediators to take care of inter-tool dependence separately. The Opal application built using mediators is configured to emulate different protection configurations show following results:
i) Performance is better in cases where tools either completely share a protection domain (same as one single Unix process) and when there are 3 different opal domains (same as Opal system)
ii) Performance is bad when domains are completely decomposed and message is passed using RPC(simulating different Unix processes)
This form of analysis is very abstract to measure performance as we are emulating just the scenario not the system calls and step by step process of what would happen.

b) Despite the use of reference counts, there can be cases where programs do erroneous pointer references. This has to be completely taken care by the user. I see this as a problem because as the size of the application grows there can be cases where user creates dangling pointers accidently. This system can cause the code to behave unpredictably and make debugging very difficult because we will be sharing data pointers across the system .
In private virtual address space systems pointers have no meaning beyond that specific process hence keeping the problem of dangling pointers localized.

c) The concepts :
1)Resource Groups - which tracks the resource and segments which thread accesses and
2)Resource Objects-which separate the counts associated with a thread for resource emanating from different entities basically to prevent untrusted threads from deleting useful information
Is a lot of information logging and will lead to huge memory being occupied by the OS itself.

Confusion

Why is copy-on-write not possible in single address space system ? A protection domain can create its own copy of data if it wants to write it by giving it a new virtual address in its own domain and inturn a new physical address.
Was this system adopted commercially at any point in time?
if not, What are major disadvantages of using this system other than virtual contiguity and conserving address space?

1. Summary
The paper introduces an Operating System - Opal, which is based on a Single Address Space. The Opal OS is suited to wide address architectures (64-bit in this paper), which eliminate the need to reuse addresses, and thereby can function without V.A. space constraints within a single address space resulting in improvements to the performance-protection tradeoff - suiting the required protection and sharing constraints of conventional systems but with lesser penalties of data sharing. Protection mechanisms as well as memory accessing/sharing which are different for this system from conventional systems are discussed and advantages of Opal compared to conventional systems are highlighted.

2. Problem
Most conventional Operating Systems use Multiple Address Spaces, with each process utilizing its own Virtual Address Space and all being mapped to portions of the Physical Address Space. Such conventional systems suffer from complexities of communication between processes (belonging to different V.A. spaces) thereby impacting performance. One instance of the complexity is the issues involved in sharing pointer information across different processes - in general, the pointers (pointing to a V.A. within a particular process) have no meaning beyond the lifetime of the process. Existing data sharing choices for private address systems are inadequate for a growing class of applications that consists of multiple programs cooperating through a pointer-rich database. The paper attempts to solve this problem by proposing a single address space where a “pointer is just a pointer” across all processes - simplifying earlier complexities of data sharing and simplification of protection while introducing some issues of its own.

3. Contributions
The paper presents an Operating System which uses a single address space across all processes, suited to wide-address architectures. The OS presents a data sharing and memory protection mechanism simpler (but equally strict) than conventional systems while cleanup is no harder. Opal separates protection from addressing, execution and resource ownership making memory protection cheaper, easier to use and change. Indirect architectural advantages from Opal also include elimination of address overloading - removing ambiguity in virtual tags in caches and the need to maintain separate per-process TLBs.

The Opal units of storage and protection are segments while those of execution are threads. Opal introduces the idea of Protection Domains - which restrict executing threads to only be able to access a specific set of segments in memory. Finer granularities of protection can be provided at the programming language levels. Opal defines a methodology of access control wherein threads are able to explicitly attach or detach themselves to protection domains with permissions to the memory segment constrained by the ‘capability’ of the domain.

Opal allows communication between threads in different domains efficiently by means of portals - each domain can create portals that permit other domains to call it in a controller manner. Applications create multiple domains, attach code/data to them and make multiple protected calls through them. Linking mechanisms are different in Opal, requiring different module instances to be mapped to different virtual addresses if needed. Opal also introduces new features to resource management and reclamation mechanisms making use of resource groups and reference objects.

The authors implement a Mach-based Opal prototype supporting its basic system abstractions.

4. Evaluation
The paper evaluates Opal atop the Boeing CAD system, showing that easier sharing of data can improve performance and scalability of real industry systems. The overlapping organization is as safe as fully decomposed configuration performs almost as well as the monolithic configuration.

Many of the issues with the single-address space approach, which are highlighted in theory (Section 6), do not influence the evaluation. More interesting results can be observed from scenarios wherein constraints of contiguity or poor resource management or copying-on-write impact the performance gains from the Opal OS in comparison to a Unix style OS.

5. Confusion
1. The paper talks about scenarios when copy-on-write is not applicable to the Opal system, while it is allowed in the case of other OS. This problem only exists when pointers in copied data must be translated - this could be a minor or a major problem. How much of an impact does this have in standard programming. Are there compiler/linking techniques to circumvent the problem?

2. It is not clear as to why virtual contiguity is a problem only for single address space systems.

3. The paper claims that clean-up is no harder in a single address space when no data is shared and that clean-up is no easier in a multi-address space when data is shared - the paper does not go into details of explaining these claims.

1. Summary

The paper discusses the Opal operating system, a single-address-space operating system designed for wide-address (64-bit) architecture. The article deals with the memory sharing and the protection provided by the complete separation of the address and protection models.

2. Problem

The goal of Opal is to enhance memory sharing while not compromising on protection, performance and integration. In private address space systems, sharing of data happened through pipes, files or messages or by placing all components in one process, causing data redundancy and loss of protection.

3. Contribution

Opal achieves its goals through the complete separation of the address and protection models. It uses a single-address space approach as a wide-address space architecture provides enough address space to facilitate this. Address overloading is eliminated, sharing of procedures and complex pointer based data structures is enhanced as the processes share the same virtual addresses. Storage allocation happens in segments and a protection domain provides the execution context for threads. It makes use of password capabilities, which is a 256-bit reference that confers permission to operate on the named objects. Inter-domain communication happens through an entry point ‘portal’(identified by portalID) using opal capabilities which is 256-bit value containing a portalID, an object address and randomised check field to verify the authority for operating on the object. The article also demonstrates the implementation of the Mach-based Opal prototype which allows coexistence of Opal with other operating system environments thus permitting bidirectional interaction between Opal and existing applications. This is because although programs in Opal share a single address space, other address space can exist on the same host.

4. Evaluation

The system is evaluated based on its performance on the Boeing CAD Systems - a large integrated application with pointer-rich data structures. The independence of the integrated tools is compromised as the source database records are accessed in a shared memory. Mediators control the tool relationship and the execution time for the different protection configurations was studied, which shows a performance increase for the read-only shared memory. The performance of Opal operations on a Mach show that destroying the domain and creating a domain from scratch is most time consuming, however it is comparable with the underlying system calls. The evaluation indicates that the performance loss on implementing the Opal as a Mach server is due to the Mach virtual memory system being designed for private address space, absence of support by Opal for native portals and because backing the memory segments by external server being costlier than the temporary virtual memory. There are no significant hidden costs to the single-address-space model and the system does not significantly add to the cost of the underlying Mach abstractions. The main concerns are the absence of virtual contiguity as programs are not free to select their segment addresses. The Opal system assumes that the address space is large enough, however efficient address conserving mechanisms are not discussed for limited addresses. The evaluation of the system on the performance, protection and integration for a shared memory was done, addressing its goal.

5. Confusion

In Opal, the operating system is coarse grained and fine grained control is left at the application level. Couldn’t understand the method and limitation of coarse grained and fine grained control.
Mach-style capabilities are the portal rights. How does this Mach-style capability differ from the portal capabilities in Opal?
Why copy-on-write is not possible on Opal systems?

1. Summary
This paper describes the details and abstractions of Opal, a single global address-space operating system designed for wide architectures. The authors also contrast the protection and memory sharing abstractions of this system against the traditional Unix style systems with multiple virtual address spaces.

2. Problem
Traditional multiple address systems provide the address space abstractions on a per-process level which simplifies protection while complicating memory-sharing. With wide architecture (64-bit) addressing, a single extremely large address space can be effectively utilised to simplify memory-sharing but convolute protection.

3. Contributions
The primary contribution of this paper is the design and implementation of single global address space system that provided flexible resource sharing and protection mechanisms. The intrinsic properties of the system simplify resource sharing between domains eliminating the need for explicit copying and inter-domain communication. The system also decoupled resource management from domain and segment protection.

Use of a single address space operating system treats all the virtual address space as a global resource controlled by the operating system.

Because of the single-address-space system, nodes can exchange addresses directly through messages in a distributed system and the addressing domain can be extended across a small workstation cluster.

Segments can be attached and detached from a segment at run time using capabilities. Any procedure becomes accessible by just knowing its address.

4. Evaluation
The authors evaluated their abstractions by prototyping atop a Mach 3.0 micro-kernel. A case study of Boeing CAD system is presented, where opal was used for the implementation of an integrated software environment and this seems to be a very specific use case. Various protection configurations (monolithic, decomposed and overlapping) have been tested for a tree-indexing program and shown that decomposed configuration perform as good as monolithic and read-only shared memory is more efficient than pipes, files, etc. Overall, the authors demonstrate that its feasible to build a single address space system with good performance on existing operating systems.

5. Confusion
What are password capabilities and how are they used ??

What happens when illegal segments are accessed ? How are these faults managed ??

What about compatibility with multi address space systems ??

The authors discuss Opal a single address space operating system designed for wide address architecture making a case that it enhances sharing, simplifies integration and improves the reliability of complex cooperating applications. The different abstractions and mechanism provided by Opal are described, it's protoype implementation on Mach and how it is suited for Boeing's CAD system performance is presented in the paper.
Problem,
In the existing private address space data sharing is primarily accomplished by copying data between private virtual memories which presents obstacles in efficient cooperation between programs.
They also enforce poor tradeoffs between protection, performance and integration as either application component have to exchange data through pipes,files, messages or place all components in one process. The authors are trying to solve this problem by using a single address space model and decoupling protection & addressing.
Contribution,
Opal uses single address space so two threads can efficiently communicate with each other using a shared memory. Although single address space model was used in capability based and object oriented OS but they suffered from insufficient hardware base and were very slow. The paper introduces coarse-grained segment based protection mechanism from the system with fine grainularity for application to be done at language & compiler level. The key notions in Opal are segments, protection domains. Segments can be attached/detached from protection domains by threads given certain capabilities and all threads executing within same protection domain can share the segments in that domain which gives orthogonality between addressing and protection.
Evaluation,
The authors implemented Opal prototype over Mach kernel and modeled the behviour through producer consumer tool. From the results overlapping organization is as safe as fully decomposed configuration and is also as fast as the monolithic configuration.
Confusion,
In the propsed model, the security of the threads needs to be looked into, as in global single shared memory the system is responsible for allocating and ensuring the segments are well protected.
To extend Opal to network systems is not efficient as address space requirement for network cluster nodes is not fixed.

The authors discuss Opal a single address space operating system designed for wide address architecture making a case that it enhances sharing, simplifies integration and improves the reliability of complex cooperating applications. The different abstractions and mechanism provided by Opal are described, it's protoype implementation on Mach and how it is suited for Boeing's CAD system performance is presented in the paper.
Problem,
In the existing private address space data sharing is primarily accomplished by copying data between private virtual memories which presents obstacles in efficient cooperation between programs.
They also enforce poor tradeoffs between protection, performance and integration as either application component have to exchange data through pipes,files, messages or place all components in one process. The authors are trying to solve this problem by using a single address space model and decoupling protection & addressing.
Contribution,
Opal uses single address space so two threads can efficiently communicate with each other using a shared memory. Although single address space model was used in capability based and object oriented OS but they suffered from insufficient hardware base and were very slow. The paper introduces coarse-grained segment based protection mechanism from the system with fine grainularity for application to be done at language & compiler level. The key notions in Opal are segments, protection domains. Segments can be attached/detached from protection domains by threads given certain capabilities and all threads executing within same protection domain can share the segments in that domain which gives orthogonality between addressing and protection.
Evaluation,
The authors implemented Opal prototype over Mach kernel and modeled the behviour through producer consumer tool. From the results overlapping organization is as safe as fully decomposed configuration and is also as fast as the monolithic configuration.
Confusion,
In the propsed model, the security of the threads needs to be looked into, as in global single shared memory the system is responsible for allocating and ensuring the segments are well protected.
To extend Opal to network systems is not efficient as address space requirement for network cluster nodes is not fixed.

1. Summary
The appearance of the 64-bit addressing on RISC processors enabled the single-address-space structure and its objective was to expand the choices in structuring of computations, the use of protection via decoupling it with addressing, and the sharing, storage and communication of data.

2. Problem
The authors claimed that Opal components could be placed in overlapping protection domains with a shared segment of memory without compromising on performance and protection; unlike the systems wherein data is copied linearly via pipes affecting performance, or where all the components are placed in the same process affecting protection.

3. Contributions
Opal abstractions - protection domains, segments, portals and resource groups have been vital in opal's design. The execution context for a set of threads is called a protection domain. Segments can be added and removed from domains using system calls, providing great flexibility in sharing memory. Portals are used for passing control between domains if the 256-bit capability consists of the apt portalID, object address and a randomized check field that verifies authority to operate on named object.
Resource Groups capability is used to increment the reference count for reclamation. An untrusted procedure subgroup can be created under the parent node of the tree of resource groups. When the untrusted procedure returns, it can be deleted ensuring the releasing of resources held by a terminating process. This is how resource ownership is decoupled from protection domains. Reference Objects ensure that an untrusted thread does not release more counts than it requested for, this avoids early deletion of shared resource. SegRef supports restricted access and selective revocation.
A lot of emphasis regarding implementation is given on usage patterns on application-level, explicit user data deletion and, compilers and language-specific runtime environments instead of operating system or hardware.

4. Evaluation
The Opal system was designed to run on Mach micro-kernel and the performance measurements done were not enough to prove that Opal will perform better than a traditional operating system under different types of loads, so the performance evaluation of this system is not comprehensive.
The claims that were made regarding maintaining modularity without affecting performance and protection don't have any appropriate empirical data to support them.

5. Confusion
What happens when an untrusted procedure tries to access a resource for which it doesn't have the capability? Is it handled by operating system or user application? The design doesn't clearly specify this aspect.
Also, is opal design used in today's modern systems?

Summary
------------
The authors of the paper propose the idea of an operating system based on single address space for the 64-bit architecture as this facilitates a sufficiently large address space for sharing among processes compared to the prevalent 32-bit architecture at that time.
The Opal model based on the above idea is presented in the paper along with the various abstractions, mechanisms, design of prototype based on the Mach 3.0 microkernel, evaluation with integrated software environments and issues due to the single address space operating system.
In entirety the paper vouches for Opal on how it achieves easy memory sharing, performance enhancement and expands choices in sharing, storage and communication of data without compromising on protection and modularity.

Problem Statement
-----------------------
Motivation : The advent of 64-bit architecture and the sudden increase in the amount of address space available to operating systems and applications is what made the authors feel the need to rethink some of the fundamental OS structure.

Problems arising out of multiple address space operating system are as follows :
Firstly, it hinders efficient communication between inter-dependent and frequently interacting applications due to the complexities involved in address mapping/translation of pointers that lose their meaning out of the private address space of a process.
Secondly, copying of data between private virtual memories necessary for sharing mechanisms (pipes, files or messages) can be expensive in case of large and sparsely used data structures.
Due to the above two problems, application designers are forced to either place all application components in independent processes which communicate through pipes, files or messages leading to poor performance or to place all components in a single process resulting in very poor protection.
Solution Approach:
Opal addresses the above problems by separating sharing and protection, which in turn provide applications with greater flexibility to share data and interact with each other. It also develops mechanisms for processes to directly access segments, without ignoring protection thereby enhancing performance.

Contributions
----------------
Opal decouples protection from program execution, resource naming, resource ownership and virtual storage. Opal contributes in the following aspects to the single address space structure in adherence to the goal of supporting modular sharing and protection. The following facilities are intended to act as a substrate for building language environments.

1) Storage and Protection
-Is coarse grained achieved through segments(contiguous virtual pages) who’s virtual address is fixed at run time and can be made persistent by use of reference counts.
-Threads are analogous to units of execution, and hierarchial protection domains is the context in which threads execute.
-Here as the segments can span across the entire address space, protection is feasible through domains that are a collection of segments accessible to threads existing in that domain.
-The authors also claim that this abstraction in easily extensible to page-based protection mechanisms on modern processors

2) Access Control
-The above mentioned protection domains and segments are known as kernel resources collectively called capabilities.
-Capability is represented by a 256 bit number containing portalID+randomized check value that allows permission
-Opal uses capabilities based on password mechanism
-A thread can access a protected domain by ‘Attach’ request that may contain various access rights but not higher than that possessed by the capability of the domain and deny access ‘Detach’
-Holder of a segment capability publishes capability + Access control list
-Runtime handler in a domain requests the capability by passing the address it faulted at.

3) Interdomain Communication
-Sharing and communication between threads across different protection domains is achieved primarily via ‘Shared Memory’
-Opal achieves this through ‘portals’ where one domain can call on portals of another domain in a protected and controlled manner.
-Hence portal can be defined as an entry point to a domain represented by a 64 value known as portalD
-Threads enter a domain by invoking a system call on the portalID of the domain
-Once entered a domain, a thread continues to execute at a global virtual address which is a fixed attribute determined by the creator of the domain facilitating the creator to control what code is executed within it.
-portalIDs also facilitate client-server model where servers can multiplex object through single portal and clients make RPC calls.
-These are implemented as proxies and guards on client and server side respectively in the Opal’s C++ interface.

4) Linking and Executing Code:
-Opal introduces the notion of a module, a group of compiled procedures along with table of symbols for code(containing memory reference instructions) and static/global variables, initial values for these variables and table for external imported symbols.
-Linker resolves these references and causes Opal modules to run at different addresses in the shared address space.
-Concurrent existence of multiple modules is made possible by the separate existence of the two regions, one where the shared module code resides and two a private version for writable static data.

5)Resource Management and Reclamation
-Reference Count: indicate number of entities that have registered an interest in a resource. ‘Attach’ increments this while ‘Detach’ decrements this.
-Resource Groups: ensure resource control policies, support bulk deletion resources, backup in failure scenario of other reclamation mechanisms, nested resources groups allow finer grain control. Accounting charges flow down root->parent->child hierarchy and Deletion privileges flow up the hierarchy.
-Reference Objects: differentiate reference counts on shared resources originating from different entities ensuring untrusted threads from performing undesired operations. SegRef is the reference object for s segment capability that support restricted access, selective revocation and can also be cloned
-Dangling References: result due to the premature deletion of objects and can be detected by using the randomized 64-bit check field. This is touted to be an access control problem.

Evaluation
------------
The Opal prototype is implemented in a Mach 3.0 microkernel to evaluate the proposal and support claims in the paper. Evaluation is carried out by deploying a Boeing’s CAD environment on this system.
Time taken for execution on three configurations namely, monolithic, decomposed and Opal styled of a tree-indexing program built using mediators is recorded. Time taken for Opal operations like segment creation, fork and exit are also recorded.
The authors have then shown through the above measurements and graphs that there is in increase in performance for an Opal based application arising out of memory sharing. They also claim that this benefits the Boeing application in terms of performance instead of message passing mechanism for frequent access to central database.
The accuracy of these claims would have been better justified had the tests been done on an isolated Opal system kernel rather than one residing on an underlying kernel as in this case. The claim for protection has also not been backed up my real statistics or tests like penetration testing of applications running on the Opal based kernel.

Confusion
------------
The paper does not clearly state or discuss the notion of how scheduling of concurrent processes are done or how synchronization of read and writes to a common shared location ensured.
The paper also does not give a clear picture of what is the state of the Opal system at startup? How many protection domains exist? Does the bootstrap program act as parent to processes/threads that start after boot?

Summary

The paper explains Opal, a single virtual address space Operating System on 64-bit architectures that decouples process security from its execution and memory organization and thereby facilitates fast data sharing for integrated applications that rely on frequent sharing of pointer-based data structures. The Opal system abstractions/ mechanisms, drawbacks against private virtual address space systems, and comparisons with similar single-address space systems previously developed have been discussed. The Opal system was implemented and evaluated through a prototype built on the Mach 3.0 micro-kernel.

Problem

Data sharing in private virtual address space operating systems relies on inefficient, inflexible mechanisms such as pipes, temp files or shared memory. These mechanisms do not allow sharing of data between processes directly through pointer values and instead rely on redundant data copies and / or intermediate representations. The tight linking between process memory protection and addressing is the chief reason for this problem.

Contributions
Opal organizes the single-address space virtual memory into contiguous extents called segments. The Opal analogue for an Unix process is the protection domain, an execution context for threads within certain set of segments. Protected procedural calls made through a protection domain's portal allow access to its restricted functionality, provided that the calling protection domain has sufficient capability (Opal equivalent for access privileges). Resource management is achieved by maintaining explicit reference counts and resource groups.

Segments are provided their own capabilities, which decouples protection from addressing. Protection domains can now easily share data through pointer values by attaching required segments to them.

Fine grained control of protection is left up to the application by using the Opal infrastructure. This contrasts the Unix view of not trusting the application. However, such measures may lead to more tedious work on the language infrastructure/programmer.

Evaluation
An Opal prototype was run as an Opal server alongside a Unix kernel with both running on top of the Mach 3.0 micro-kernel. Opal based applications directly interacted with the Opal server for segment allocation / attach / detach,  protection domain creation and access to a portal. Key Opal primitives were timed and these timings were compared against Unix equivalent actions. The authors also discuss the Boeing CAD example and mediators framework to highlight the type of applications which Opal is suited for. The monolithic, overlapping and decomposed mediators were compared for performance on such an application. The authors conclude that Opal provides competitive performance compared to Unix based systems. Opal drawbacks such as lack of segment growth, memory address recycling, fork() equivalent system call and the copy-on-write mechanism are also evaluated.

The authors indicate that a native Opal kernel with performance tuning would provide significant performance benefits over Unix. However, without actual testing, no definite comment can be made regarding the actual performance speedup that could be offered by an optimized Opal implementation.

Questions
How is resource naming defined in the context of an operating system?
What are password capabilities?
Was a practical full-scale implementation of an Opal-like system, (with optimized performance tuning on a supporting hardware) ever built? If yes, what issues (besides the ones mentioned in the paper) did it face?

1. Summary

The Opal paper talks about improving the performance of pointer-rich applications by simplifying data sharing and communication between multiple cooperating processes through separation of protection and addressing within a single-address-space operating system design facilitated by the introduction of 64-bit wide architecture.

2. Problem

There has been a growing class of applications like CAD, CASE etc. that consist of highly interactive cooperating processes that need to share pointer-rich data among them. However, restrictions of a private virtual address space entail that the pointer-based data cannot be easily shared, stored or transmitted beyond the boundaries of the private virtual address space.  The primary co-operation mechanisms for data sharing between private memories of different processes then rely upon message passing or use of shared memory, which lead to poor tradeoffs between protection, performance and integration for such kind of applications. The authors want to solve this problem by introducing a single global virtual address space that is shared by all procedures and all data, coupled with separation of protection and addressing. 

3. Contributions

The single-address-space and uniform addressing concepts for operating system design are not new and have been explored in previous capability-based and object-based operating systems. However, the novel contribution of this paper has been the solution to the problem of overly complex and slow design of the previous systems by replacing the needs for special-purpose hardware or a single type-safe language through a coarse-grained segment-based protection mechanism over 64-bit wide architecture. The paper introduces the idea of a global address space with context independent unique virtual addresses that simplify sharing between applications by exploiting the newly introduced 64-bit architectures to eliminate the need for address reuse.

The key abstractions introduced in Opal are segments, protection domains, threads, portals and resource groups. Segments are contiguous section of virtual pages allocated at globally identifiable fixed virtual addresses, while protection domains denote a context for thread execution for a given collection of segments. Opal defines capabilities for various resources as a means for access control. Segments can be attached/detached from protection domains dynamically by threads given certain capabilities and all threads executing within same protection domain can share the segments belonging to that domain. This leads to separation between addressing and protection – another key contribution of Opal, that provides added performance and safety relative to current implementation choices on conventional operating system for pointer-rich applications.

4. Evaluation

The authors have evaluated Opal by creating an Opal prototype over a Mach 3.0 kernel. To model a use-case of an application consisting of highly cooperative processes sharing pointer-rich data, they came up with a producer-consumer tool, where manipulations to a complex data structure by a producer will be replicated in a consumer through a mediator. From their results, it can be concluded that an “overlapping” organization consisting of overlapped protection domains between producer and consumer is not only as safe as the fully “decomposed” configuration, but is also nearly as fast as the “monolithic” configuration.

5. Confusion 

The evaluations have shown performance comparison for applications that involve sharing of pointer-rich data. Is the Opal model as performant even for stand-alone applications that do not share any data?

How secure is the capabilities-based access control mechanism for Opal? Can a malicious thread manipulate a 256-bit capability to gain unauthorized access to segments? This seems an even bigger concern when Opal model is applied in a distributed network setting.

1. Summary

The Opal paper talks about improving the performance of pointer-rich applications by simplifying data sharing and communication between multiple cooperating processes through separation of protection and addressing within a single-address-space operating system design facilitated by the introduction of 64-bit wide architecture.

2. Problem

There has been a growing class of applications like CAD, CASE etc. that consist of highly interactive cooperating processes that need to share pointer-rich data among them. However, restrictions of a private virtual address space entail that the pointer-based data cannot be easily shared, stored or transmitted beyond the boundaries of the private virtual address space.  The primary co-operation mechanisms for data sharing between private memories of different processes then rely upon message passing or use of shared memory, which lead to poor tradeoffs between protection, performance and integration for such kind of applications. The authors want to solve this problem by introducing a single global virtual address space that is shared by all procedures and all data, coupled with separation of protection and addressing. 

3. Contributions

The single-address-space and uniform addressing concepts for operating system design are not new and have been explored in previous capability-based and object-based operating systems. However, the novel contribution of this paper has been the solution to the problem of overly complex and slow design of the previous systems by replacing the needs for special-purpose hardware or a single type-safe language through a coarse-grained segment-based protection mechanism over 64-bit wide architecture. The paper introduces the idea of a global address space with context independent unique virtual addresses that simplify sharing between applications by exploiting the newly introduced 64-bit architectures to eliminate the need for address reuse.

The key abstractions introduced in Opal are segments, protection domains, threads, portals and resource groups. Segments are contiguous section of virtual pages allocated at globally identifiable fixed virtual addresses, while protection domains denote a context for thread execution for a given collection of segments. Opal defines capabilities for various resources as a means for access control. Segments can be attached/detached from protection domains dynamically by threads given certain capabilities and all threads executing within same protection domain can share the segments belonging to that domain. This leads to separation between addressing and protection – another key contribution of Opal, that provides added performance and safety relative to current implementation choices on conventional operating system for pointer-rich applications.

4. Evaluation

The authors have evaluated Opal by creating an Opal prototype over a Mach 3.0 kernel. To model a use-case of an application consisting of highly cooperative processes sharing pointer-rich data, they came up with a producer-consumer tool, where manipulations to a complex data structure by a producer will be replicated in a consumer through a mediator. From their results, it can be concluded that an “overlapping” organization consisting of overlapped protection domains between producer and consumer is not only as safe as the fully “decomposed” configuration, but is also nearly as fast as the “monolithic” configuration.

5. Confusion 

The evaluations have shown performance comparison for applications that involve sharing of pointer-rich data. Is the Opal model as performant even for stand-alone applications that do not share any data?

How secure is the capabilities-based access control mechanism for Opal? Can a malicious thread manipulate a 256-bit capability to gain unauthorized access to segments? This seems an even bigger concern when Opal model is applied in a distributed network setting.

1. Summary
In this paper the authors present Opal, a single-address-space operating system designed mainly for 64-bit address space architectures. In contrast to the conventional operating systems, Opal features the uniform interpretation of addresses, the orthogonality of addressing and protection, and simplified sharing of data among processes without sacrificing the protection offered by conventional systems.

2.Problem
On conventional multiple-address-space based systems, pointers have no meaning beyond a particular process that owns them and thus introduce unnecessary complexity (since applications can only communicate via pipes, files or messages) and / or inefficiency (if applications place all components in one process). With increasing number of advanced applications with large groups of independent data-centered tools and rich interactions among them, it is important to improve on the sharing, integration, reliability and performance of such complex applications. Opal, a single-address-space operating system, addresses this by decoupling protection from addressability and eliminating the problems with non-uniform addressing by treating all virtual address space as a global resource.

3.Contributions
One of the novel contributions from this paper is the introduction of single-address-space. With this concept, processes can exchange data by sharing pointers since they are mapped globally, which is not possible in other conventional systems. This eliminates the necessity to convert data into primitive form and communicate using pipes, files or messages of some form, which authors repeatedly argue to be more efficient and simpler. The address can also be shared among other nodes in a distributed setting that eliminates the necessity to use RPC to communicate.
Another key contribution is the separation of protection and addressing that makes it cheaper, easier to use and flexible to change. For resource management and reclamation, the authors explain how the resource groups and reference objects decouple resource ownership from protection domains.

4.Evaluation
The authors built a prototype of this system on top of Mach microkernal and reported that the performance was “competitive” with other conventional environments. It looks promising, especially given that it was not a native Opal kernal implementation and several possible optimizations were not pursued on this prototype.
However, this OS falls short in aspects. Apart from the ones mentioned by the authors, such as the prototype does not support crash recovery, possible limits on the use of contiguous data structures and unsupportable unix-style-fork, the authors’ argument that this is well suited for applications like CAD seems too specific of a use-case and allows readers only limited space to generalize.

5.Confusion
-Since any program can read and possibly modify other program’s data, how sound is the argument that it is as much (if not more) secure?
-How about synchronization cost when processes are trying to access shared memory? (Since this model encourages the sharing of memory addresses)
-It does not seem like it is scalable for distributed system of reasonable length. How do you deal with the failures of nodes that is the original container of a particular pointer that is shared?
-The applications need to worry too much about the implementation details by having to architect around the layer of memory addresses and thus takes away appropriate levels of abstractions.

1.Summary:
This paper focuses on design and evaluation of Opal, a single address space operating system on 64 bit wide architectures, decoupling protection and addressing, unlike a private address space OS, thus improving sharing and protection. Implementation of Opal has been done on top of Mach kernel.

2.Problem:
The disadvantages of private address space operating systems are as follows:
a. Co-operation and pointer based data sharing is difficult between application components because they have no meaning outside each other's address spaces.
b. Memory sharing requires prior co-ordination of address space for shared regions, having the need to know sharing patterns statically.
c. Data sharing mechanisms such as pipes, files or messages drastically affects performance and placing all components in one process affects protection.
Opal tries to resolve these by having a single virtual address space system, separating protection from addressing.

3.Contributions:
a. Having a single global virtual address space makes sharing easier among the processes, by allowing access to other process' protected domain(here, execution context of threads) through protected procedure calls.
b.Protection is decoupled from addressing by having separate access control mechanisms for memory segments. This allows asymmetric trust relationships and thus great flexibility.
c.Resource management is done by maintaining explicit reference counts in the form of resource groups, enabling bulk cleanup and reference objects to avoid erroneous release of resources.

4.Evaluations:
a.The authors have implemented the Opal features by building Opal server on top of Mach 3.0 micro-kernel Operating system making it possible to utilize Unix utilities to debug during development.
b.The Opal prototype has been studied for integrated software environments like Boeing's CAD environment. Data sharing between independent tools using different data formats is an issue, which the authors solve by implementing 'mediators' between different tools.
c.The authors show that the performance of Monolithic and Overlapping protection configurations in Opal is nearly the same, using tree-indexing program.
d.The authors also compare domain/segment creation time with Unix fork and other system calls' times to show that performance of Opal is as good as other environments supported by the kernel. But this itself is not a good performance measure for the Opal system independently, due to overhead presented by the underlying kernel.

5.Confusion:
Why aren't there Opal kernel implementations as opposed to building the system on top on micro kernels?

1. Summary
Opal is a Single Address Space OS that simplifies the sharing of pointer-based structure in integrated environments by decoupling addressing from protection and utilizing wide-address architecture.

2. Problem
The target problem of Opal is the sharing of pointer-based data structures between a set of highly interdependent tools. Traditional systems following the private address space principle achieve this in two ways: putting all components in a single process thus sacrificing protection, or communicating with intermediate representations without pointers, which sacrifices performance instead.

3. Contributions
The authors addressed the above issue by developing various protection mechanisms on top of a single address space system, where pointers are context-independent and can be shared without modification. They decoupled protection from addressing by introducing protection domains and allow them to overlap. The ability to name an address does not necessarily mean access permissions. Protected interdomain calls are achieved via portals. A hierarchy of resource groups are used to do cleanup.

4. Evaluation
They built an Opal prototype on Mach microkernel alongside a Unix server. Applications on Boeing’s CAD system are discussed but no detailed evaluation results are given. Instead, the authors implemented a small mediator-based program and showed that Opal in overlapping configuration can achieve protection as decomposed while working as fast as monolithic. Performance of Opal primitives are also compared to those of Unix’s. The results are acceptable and they argue better results may be achieved by (1) doing some tuning; (2) building a native Opal kernel.

5. Confusion
This paper does not make it clear whether the secondary storage is visible to the application or transparent, as segments in the single address space can be persistent by using backing files and inactive segments are also mentioned. It is an interesting idea to have a single address space for main memory, secondary memory and even memory over the network.

Summary

The paper challenges the conventional wisdom of private virtual address spaces for program execution and propose a single address space operating system called Opal. Opal can exploit the modern 64-bit processors to meet the dual goal of protection and performance simultaneously without having a need for a special purpose hardware or type-safe language.

Problem

In order to ensure protection among various programs that are running within an Operating system, the native approach is to intertwine the addressing and accessibility. It means that the right to access data is restricted by the context of the program execution within its own private address range. This mechanism is used by multiple-address-space system where each program has its own separate virtual address space. Multiple-address-space approach surely increases the amount of address space available and ensures protection but at the same time impacts the data sharing and performance significantly. The only way of communication between two processes is via data sharing using a neural intermediate representation which is inefficient. This poses a challenge to a new breed of applications that are highly interactive and share data extensively as the application developer faces a trade-off between protection and performance. Moreover, with the 64-bit addressing scheme, ample address space will be available without the need of having multiple address space.

Contribution

The most significant contribution of this paper is to isolate the addressing and accessibility/protection aspects and make addressing context-independent so that every process sees just one single view of the entire data. This makes data sharing very simple, efficient and fast as the all the processes have the capability of accessing any data within the system provided the access is allowed. Opal defines segments that is seen as a basic unit of sharing among processes.

Another contribution of this paper is of decoupling fine grained protection control from the operating system and giving that control to the languages and runtime. The segments are tied to a domain(execution context of threads)) that restricts the access of the segments at any particular instance. Domains and segments are provided with a capability that specifies the access control information for ensuring protection. This allows any thread to attach/detach the segment as the capability can be shared easily in the shared memory.

A new abstraction called portal allows the threads to switch domains so that any thread can enter/exit portals and execute from a different domain. However, Opal has its own share of problems that the authors solve by employing clever tricks at the compiler/linker level. Private static data needs special handling as each instance needs to have a separate location. This is ensured by using register-relative addressing where the base values are assigned dynamically.

A less discussed but important topic here is that the concept of using single address space can be used to accommodate the data across a network. This really has potential to make a true scalable system where nodes often share/store data from different nodes.

Evaluation

In order to quickly demonstrate the strength and weakness of the single-address space system, the authors implemented Opal on top of Mach 3.0 microkernel OS. This also shows that the conventional and the new proposed system can work hand-in-hand without any problem. The authors describe the Boeing CAD system in detail to explain how Opal can address the needs of a real world system.

The authors provide performance gains by Opal to confirm that the premise of having a single-address space holds ground. However, I feel that the evaluation done is very limited to confirm that single-address space system will always perform better than the traditional operating system. There is nothing in the evaluation that shows that single address space system is indeed providing the same protection as provided by multi-address space system. This is disappointing as evaluation doesn't back up the claims made.

Confusion

What happens when an illegal access happens? Who handles the protection fault - Opal or the application?

Summary
This paper proposes and implements a new OS structure, Opal, that leverages the wide address space in the new 64-bit architecture by offering a single-address-space OS with efficient memory sharing and protection support, majorly targeting/benefiting highly inter-dependent and interactive applications.

Problem
Multiple private address space OS inherently fails to provide convenient protection and sharing mechanisms: complex address translations, reuse addresses, pointer-passing is ambiguous or require complex prior-coordination, copying data is wasteful and expensive. And such an OS approach of a private-address-space-per-process fails to simultaneously achieve efficient protection and performance. Thus, the systems become slow and unreliable.

Contributions
With the advent of wide address space architectures, it is possible to do away with complex address translations and reusing addresses. Opal treats the entire address space as a single global resource(different from the multics notion where programs do not use global address directly). Major ideas are-
1. Decoupling protection and addressing: This increases flexibility, makes protection easier and cheaper, makes sharing procedures and pointers convenient. The abstractions are coarse-grained at OS level, for example assigning the size of segments and the partitions inside segments.
2. Capabilities: that permit objects to operate on a segment.
3. Portals for inter-domain communication: this global entry point to a domain allows threads with portal id to enter the domain with access controlled by the owner of the domain.
4. Reference count provide simple resource management, and resource groups to enforce policies and allow bulk delete.

It is very detailed paper and discusses the benefits, deviations and issues with the proposed approach. Overall, this approach is good- clear boundaries on access, efficient use of the address space, simplified model for sharing(unambiguous references) and addressing(no translation levels), but not generic: may not be suitable for applications that require contiguous data structures exceeding the segment boundaries, or are not highly interfering.

Evaluation
Opal is implemented on Mach microkernel with a standard runtime package. They have evaluated on an interactive software that manipulates a shared database. The system is evaluated on its performance with the number of records against various protection configurations (monolithic, decomposed and overlapping). Increased sharing leads to an increased performance, but not clear on how they justify that overlapping is safe. They also present performance of Opal’s operations- effects of caching domains and Opal's cross-domain calls ~ Mach's cross-address calls.

Confusion
The notion of password capabilities isn’t detailed. How is it different from Mach’s port rights, and how is it easier due to this shared memory?
Struggled to realize the advantage of Opal’s way of addressing the private static data, and reference objects.

1. Summary
The paper presents Opal, a single-address-space operating system designed for wide-address architectures, which is a big departure from conventional multiple-address-spaces design. The authors claim that the conventional OS designs impose complexities that are unnecessary, especially in view of the availability of modern 64-bit hardware to run the desired highly integrated applications. Opal, on the other hand, enables efficient data sharing since it decouples protection from addressing, thus providing more flexibility in performance-protection trade-offs.

2. Problem
Integrated application systems, for example CAD softwares being developed by Boeing, consist of multiple programs working together and benefit from efficient data sharing between these programs. In conventional OS design, processes (programs) are isolated with hard protection boundaries as they operate in their private address spaces. This inherently makes sharing of data (for example virtual pointer based data structures) hard, thus forcing the use of complex low performing sharing techniques. A second issue is the poor trade-off between protection, performance and integration in application design.

3. Contributions
The authors claim that a single-address-space OS, Opal, is well suited to the modern applications. It is based on ideas similar to those presented in prior works like segmented systems and capability-based architectures. However, it outperforms each of those on one or more fronts - it can be implemented on stock processor without any special hardware changes, it supports multiple safe and unsafe languages, it supports virtual pointer based data sharing on more diverse platforms. It can be easily extended to local networks with persistent storage.

The paper discusses various abstractions and mechanisms that have been devised to build Opal on existing operating systems, a majority of which have actually been used in a prototype developed using Mach 3.0 microkernel as base. Opal uses capabilities and protection domains to control the access to resources. It has elaborate schemes for communication between domains using the concept of portals. It has special pre- and post-processing utilities to handle linking of code modules, which becomes complicated due to uniform addressing across “programs” in Opal. All these and much more enable building of a single-address-space OS, which is the biggest contribution of this work. Effectively, this makes memory protection highly flexible and lightweight by eliminating its dependence on addressing.

4. Evaluation
The Opal prototype has been evaluated using Boeing CAD systems. Using mediator based organization, the experiments demonstrate that Opal offers the performance comparable to that of a monolithic protection domain, while allowing freedom to actually have the desired safety barriers between processes. The paper also presents the latency numbers for various Opal primitives.

Though the results look good, the study would have been more convincing if more exhaustive experimental analyses was presented involving more applications, different structuring paradigms (besides mediators). It would also be interesting to see how the performance on Opal compares against the applications running on actual Unix systems (not against Unix environment simulated inside Opal). Linking of programs that have multiple instances of modules with mutable private data is admittedly a crippling issue which has not been quantified well. This is even more crucial in the modern context with highly encapsulated object oriented programming paradigms.

5. Confusion
The paper mentions that Opal systems can use copy-on-write at every place where a conventional OS can do so, except when a pointer in copied data needs to be “translated”. This has not been explained well. An example to illustrate a situation that requires such “translation” would be quite helpful.
Use of portals for inter-domain communication and passing of capabilities is not very clear. I would like to understand the details of how it works.

1. Summary
The paper presents Opal, a single-address-space operating system designed for wide-address architectures, which is a big departure from conventional multiple-address-spaces design. The authors claim that the conventional OS designs impose complexities that are unnecessary, especially in view of the availability of modern 64-bit hardware to run the desired highly integrated applications. Opal, on the other hand, enables efficient data sharing since it decouples protection from addressing, thus providing more flexibility in performance-protection trade-offs.

2. Problem
Integrated application systems, for example CAD softwares being developed by Boeing, consist of multiple programs working together and benefit from efficient data sharing between these programs. In conventional OS design, processes (programs) are isolated with hard protection boundaries as they operate in their private address spaces. This inherently makes sharing of data (for example virtual pointer based data structures) hard, thus forcing the use of complex low performing sharing techniques. A second issue is the poor trade-off between protection, performance and integration in application design.

3. Contributions
The authors claim that a single-address-space OS, Opal, is well suited to the modern applications. It is based on ideas similar to those presented in prior works like segmented systems and capability-based architectures. However, it outperforms each of those on one or more fronts - it can be implemented on stock processor without any special hardware changes, it supports multiple safe and unsafe languages, it supports virtual pointer based data sharing on more diverse platforms. It can be easily extended to local networks with persistent storage.

The paper discusses various abstractions and mechanisms that have been devised to build Opal on existing operating systems, a majority of which have actually been used in a prototype developed using Mach 3.0 microkernel as base. Opal uses capabilities and protection domains to control the access to resources. It has elaborate schemes for communication between domains using the concept of portals. It has special pre- and post-processing utilities to handle linking of code modules, which becomes complicated due to uniform addressing across “programs” in Opal. All these and much more enable building of a single-address-space OS, which is the biggest contribution of this work. Effectively, this makes memory protection highly flexible and lightweight by eliminating its dependence on addressing.

4. Evaluation
The Opal prototype has been evaluated using Boeing CAD systems. Using mediator based organization, the experiments demonstrate that Opal offers the performance comparable to that of a monolithic protection domain, while allowing freedom to actually have the desired safety barriers between processes. The paper also presents the latency numbers for various Opal primitives.

Though the results look good, the study would have been more convincing if more exhaustive experimental analyses was presented involving more applications, different structuring paradigms (besides mediators). It would also be interesting to see how the performance on Opal compares against the applications running on actual Unix systems (not against Unix environment simulated inside Opal). Linking of programs that have multiple instances of modules with mutable private data is admittedly a crippling issue which has not been quantified well. This is even more crucial in the modern context with highly encapsulated object oriented programming paradigms.

5. Confusion
The paper mentions that Opal systems can use copy-on-write at every place where a conventional OS can do so, except when a pointer in copied data needs to be “translated”. This has not been explained well. An example to illustrate a situation that requires such “translation” would be quite helpful.
Use of portals for inter-domain communication and passing of capabilities is not very clear. I would like to understand the details of how it works.

1. Summary
The paper presents Opal, a single-address-space operating system designed for wide-address architectures, which is a big departure from conventional multiple-address-spaces design. The authors claim that the conventional OS designs impose complexities that are unnecessary, especially in view of the availability of modern 64-bit hardware to run the desired highly integrated applications. Opal, on the other hand, enables efficient data sharing since it decouples protection from addressing, thus providing more flexibility in performance-protection trade-offs.

2. Problem
Integrated application systems, for example CAD softwares being developed by Boeing, consist of multiple programs working together and benefit from efficient data sharing between these programs. In conventional OS design, processes (programs) are isolated with hard protection boundaries as they operate in their private address spaces. This inherently makes sharing of data (for example virtual pointer based data structures) hard, thus forcing the use of complex low performing sharing techniques. A second issue is the poor trade-off between protection, performance and integration in application design.

3. Contributions
The authors claim that a single-address-space OS, Opal, is well suited to the modern applications. It is based on ideas similar to those presented in prior works like segmented systems and capability-based architectures. However, it outperforms each of those on one or more fronts - it can be implemented on stock processor without any special hardware changes, it supports multiple safe and unsafe languages, it supports virtual pointer based data sharing on more diverse platforms. It can be easily extended to local networks with persistent storage.

The paper discusses various abstractions and mechanisms that have been devised to build Opal on existing operating systems, a majority of which have actually been used in a prototype developed using Mach 3.0 microkernel as base. Opal uses capabilities and protection domains to control the access to resources. It has elaborate schemes for communication between domains using the concept of portals. It has special pre- and post-processing utilities to handle linking of code modules, which becomes complicated due to uniform addressing across “programs” in Opal. All these and much more enable building of a single-address-space OS, which is the biggest contribution of this work. Effectively, this makes memory protection highly flexible and lightweight by eliminating its dependence on addressing.

4. Evaluation
The Opal prototype has been evaluated using Boeing CAD systems. Using mediator based organization, the experiments demonstrate that Opal offers the performance comparable to that of a monolithic protection domain, while allowing freedom to actually have the desired safety barriers between processes. The paper also presents the latency numbers for various Opal primitives.

Though the results look good, the study would have been more convincing if more exhaustive experimental analyses was presented involving more applications, different structuring paradigms (besides mediators). It would also be interesting to see how the performance on Opal compares against the applications running on actual Unix systems (not against Unix environment simulated inside Opal). Linking of programs that have multiple instances of modules with mutable private data is admittedly a crippling issue which has not been quantified well. This is even more crucial in the modern context with highly encapsulated object oriented programming paradigms.

5. Confusion
The paper mentions that Opal systems can use copy-on-write at every place where a conventional OS can do so, except when a pointer in copied data needs to be “translated”. This has not been explained well. An example to illustrate a situation that requires such “translation” would be quite helpful.
Use of portals for inter-domain communication and passing of capabilities is not very clear. I would like to understand the details of how it works.

1. Summary
The paper explains the Opal System. A single address space Operating System for wide address( 64 bit) Architectures. The paper explains how sharing is simplified and protection is still maintained. Opal is implemented on Mach 3.0 microkernel and performance for CAD system is discussed.

Problem
The author specifies the problem of Private address spaces.In Private Address Space for memory protection - it isolates programs within private virtual address spaces which is an obstacle to efficient cooperation .Pointers has no meaning outside process lifetime. And sharing through copying data to an intermediate format is expensive for large or sparse data structures.Application designer can either place components in separate process and exchange through pipes/messages or place components in single process which affects protection.Private address space force poor tradeoffs between protection,performance and integration.
So Author suggests that to use 64 bit architecture as single address space to simplify sharing without any loss of protection

Contribution
The key contribution of Opal was separation of Protection and Addressing using a single shared virtual address space.
Procedure can share data at any time without requiring a priori address coordination.
Protection domains which are independent of addressing determine which thread executes and access rights to memory segments which help in sharing easily.
Segments are dynamically created and shared through capabilities through dynamic linking.
Introduce the concept of portals which allows a thread to execute code in other domains by specifying the starting point.Resource protection
Storage allocation,protection and reclamation is coarse grained managed by OS and fine grained control is left for compilers and run time systems

Evaluation
The Paper gives the performance results of Prototype of Opal implemented on top of mach 3.0 microkernel which was evaluated for Boeing CAD system.A Mediators based application was used to illustrate the structuring options and their performance. Performance of application with number of records passing and execution time for 3 tree indexing configurations Monolithic,Decomposed, Overlapping is given.The performance of Monolithic and overlapping increases relative to decomposed as shared data increases.
The author specifies the time taken for opal operations segment creation ,attach/detach, cross domain call and domain management operations and specifies that they are reasonable in performance by comparing with Unix fork/exit etc operations. All these results doesn't seem to be concrete as the proper performance evaluation which should be of a native Opal kernel implementation was not done.

Confusion
The linking module - Refine/Resolve is still not clear.
Details on how actually password capabilities are implemented.
"Dangling capabilities are detectable using 64 bit check field" - would be great if you could elaborate this.

1.Summary
The paper presents a single-address-space operating system Opal for wide address (64 -bit) architecture designed to support simple sharing,flexible protection and persistent storage. All addresses are unique, for all applications, and potentially through all time. The paper discusses a proof of concept and the design choices to this end. Threads are the units of execution in Opal and they are associated with a context called protection domains which determine their access rights to memory segments via password capabilities.
2.The problem
The main issue with private address space is that sharing of data is very cumbersome and it has poor trade offs between protection performance and integration (especially for groups of programs cooperating through a shared pointer-rich database). Sharing is either done by placing the components in independent processes and exchanging data via pipes, files or messages, which takes a toll on the performance or by placing all the components in a single process which hinders protection. Moreover sharing via pointers require sharing patterns to be static and a priori coordination of address space for shared regions. Another motivation for a single-address-space system is that wide address architecture can eliminate the need to reuse data as is the case for 32-bit architectures.
3.Contributions
1.Main contribution of Opal is the provision for context independent address and orthogonality of address and protection. It has a single address space where all virtual addresses are treated as a global resource controlled by OS. Memory segments are dynamically created and dynamically shared via password capabilities.
2.Address overloading overhead is removed as now there is no need to maintain per process virtual-physical translation tables.
3.Nodes can exchange addresses and pointer rich data structures directly through message in a distributed,persistent single-address space system.
4.Opal also decouples of program execution (via RPC),resource ownership(via resource groups) and resource naming( via context-independent capabilities based on portals) from protection domain which results in cheaper and easier memory protection .
5.Any thread can dynamically attach and call accessible procedures simply via their addresses which is a novel concept.
6.It supports coexistence with other OS environments on microkernels which permits experimentations while continuing to work with existing ones.
7.All the above features are provided without special purpose hardware(eg:capability based Intel 432), without loss of protection or performance and without requiring the single type -safe programming language (eg- Xerox Pilot).

3.Flaws
1.There is no backward compatibility with private-address-space operating systems unlike PA_RISC e
wide address architecture eliminates reuse of addresses
2.In Opal, an executing thread can attach a segment to its protection domain making it accessible for all the others threads in the domain as well. This means the threads executing in the same domain should have a high level of trust amongst them.
3.The authors do not state how synchronization is done and how racing condition is prevented for shared memory.

4.Evaluation
The paper presents experiment results of using Opal prototype for Boeing's aircraft CAD system which is a large integrated application with pointer-rich data structures. The framework used is that of a structuring paradigm called mediator which factors out inter-tool dependences and communication occurs through events during updation. The paper analyses the performances of a simple producer and consumer application under three protection configurations:
i)Monolithic: A single protection domain is shared amongst all tools and the mediator.
ii)Decomposed : Here the producer is in protection domain while the consumer and the mediator are in a separate two non-overlapping domain.
iii)Overlapping : Here there are three Opal domains with the mediators domain having read access to the producer and read write to the consumer.
It is observed that the overlapping configuration achieves high performance of monolithic and the protection of decomposed configuration. Also analysis of some Opal primitives implemented over Mach kernel on a Digital Alpha processor showed that 1) they have reasonable performances competitive with other environments like Unix 2)they do not add significantly to the cost of underlying Mach abstractions.

5.Confusions
What is meant by persistent but inactive data in the context of a distributed single-address-space system ?
What is the purpose of having separate reference objects and reference counts? Will not the count of reference objects substitute for the need of reference counts?
What is meant by coarse grained and fine grained control of storage allocation, protection and reclamation?
What are the reasons why OPAL or similar architectures have not been adopted commercially despite the possible advantages?

1.Summary
The paper presents a single-address-space operating system Opal for wide address (64 -bit) architecture designed to support simple sharing,flexible protection and persistent storage. All addresses are unique, for all applications, and potentially through all time. The paper discusses a proof of concept and the design choices to this end. Threads are the units of execution in Opal and they are associated with a context called protection domains which determine their access rights to memory segments via password capabilities.
2.The problem
The main issue with private address space is that sharing of data is very cumbersome and it has poor trade offs between protection performance and integration (especially for groups of programs cooperating through a shared pointer-rich database). Sharing is either done by placing the components in independent processes and exchanging data via pipes, files or messages, which takes a toll on the performance or by placing all the components in a single process which hinders protection. Moreover sharing via pointers require sharing patterns to be static and a priori coordination of address space for shared regions. Another motivation for a single-address-space system is that wide address architecture can eliminate the need to reuse data as is the case for 32-bit architectures.
3.Contributions
1.Main contribution of Opal is the provision for context independent address and orthogonality of address and protection. It has a single address space where all virtual addresses are treated as a global resource controlled by OS. Memory segments are dynamically created and dynamically shared via password capabilities.
2.Address overloading overhead is removed as now there is no need to maintain per process virtual-physical translation tables.
3.Nodes can exchange addresses and pointer rich data structures directly through message in a distributed,persistent single-address space system.
4.Opal also decouples of program execution (via RPC),resource ownership(via resource groups) and resource naming( via context-independent capabilities based on portals) from protection domain which results in cheaper and easier memory protection .
5.Any thread can dynamically attach and call accessible procedures simply via their addresses which is a novel concept.
6.It supports coexistence with other OS environments on microkernels which permits experimentations while continuing to work with existing ones.
7.All the above features are provided without special purpose hardware(eg:capability based Intel 432), without loss of protection or performance and without requiring the single type -safe programming language (eg- Xerox Pilot).

3.Flaws
1.There is no backward compatibility with private-address-space operating systems unlike PA_RISC e
wide address architecture eliminates reuse of addresses
2.In Opal, an executing thread can attach a segment to its protection domain making it accessible for all the others threads in the domain as well. This means the threads executing in the same domain should have a high level of trust amongst them.
3.The authors do not state how synchronization is done and how racing condition is prevented for shared memory.

4.Evaluation
The paper presents experiment results of using Opal prototype for Boeing's aircraft CAD system which is a large integrated application with pointer-rich data structures. The framework used is that of a structuring paradigm called mediator which factors out inter-tool dependences and communication occurs through events during updation. The paper analyses the performances of a simple producer and consumer application under three protection configurations:
i)Monolithic: A single protection domain is shared amongst all tools and the mediator.
ii)Decomposed : Here the producer is in protection domain while the consumer and the mediator are in a separate two non-overlapping domain.
iii)Overlapping : Here there are three Opal domains with the mediators domain having read access to the producer and read write to the consumer.
It is observed that the overlapping configuration achieves high performance of monolithic and the protection of decomposed configuration. Also analysis of some Opal primitives implemented over Mach kernel on a Digital Alpha processor showed that 1) they have reasonable performances competitive with other environments like Unix 2)they do not add significantly to the cost of underlying Mach abstractions.

5.Confusions
What is meant by persistent but inactive data in the context of a distributed single-address-space system ?
What is the purpose of having separate reference objects and reference counts? Will not the count of reference objects substitute for the need of reference counts?
What is meant by coarse grained and fine grained control of storage allocation, protection and reclamation?
What are the reasons why OPAL or similar architectures not been adopted commercially despite its possible advantages?

Summary:

In a world where the current addressing capacity of modern 64 bit processors is much larger than that of 32 bit processors, the use of a single global virtual address will suit a wide variety of use cases and integrated applications. This paper mainly intends to discuss the feasibility of implementing such a system (opal) with well-defined abstractions and mechanisms for storage, protection, access control and inter protection domain communication and also evaluating it.

Problem:

Traditional operating systems have a separate virtual address space per process to enforce memory protection, but this can lead to unnecessarily excessive message passing in the case of well integrated applications that interact with each other constantly and access a lot of shared data (which changes over time), leading to a trade off in performance for enhanced security imposed by the operating system to ensure correctness, which is not required for such applications.

Contribution

1. Explains the advantages and disadvantages of a single global virtual address space. Advantages being dynamic sharing of addresses, dynamic linking of shared libraries and also avoiding unnecessary message passing of large data structures. Disadvantages being the requirement to include additional abstractions and mechanisms to improve reliability and protection.

2. The paper provides the description of the separation of addressing from protection using protection domains in Opal and also the mechanisms that help achieve such coarse grained protection, access control and inter-domain communication with the help of capabilities and portals in protection domains. It again defines segments, protection domains, resource groups and reference objects and their importance.

3. The paper describes the implementation of an opal prototype over a mach microkernel which contains an opal server and a runtime package. The Opal server maintains the virtual address to segment mapping, interacts with the inode pager that provides a persistent backing store for mach objects, creates new protection domains with a standard template and maintains information about the kernel resources. The runtime package handles inter-domain communication and also helps perform dynamic translation of portalID to mach ports.

4. In order to support the case of a single shared address space system, the paper describes the use case of CAD tools and structuring integrated tools that greatly benefit from the shared memory architecture as it involves multiple consumers relying on a common database, that could potentially be shared.

5. It also addresses a few basic issues in this model such as a potential unavailability of contiguous memory addresses for segments in smaller address spaces, difficulty in recycling resources but eventually claims that such issues will be non-existent in larger address spaces and also touches upon the inability to perform a copy on write.

6. Finally, it compares the opal system to previous systems that it draws ideas from, such as the multics system that uses similar abstractions but uses individual virtual address spaces for processes that map onto a global shared virtual address space, the concept of capabilities from Levy and Fabry but improving the granularity of protection to protection domains from words.

Evaluation

Implemented the opal prototype over the mach microkernel. A mediator based framework has been implemented for structured integrated tools using multiple configurations and a tree indexing program has been evaluated to show that an overlapping configuration is as performant as a monolothic configuration and logically provides protection equivalent to that of a decomposed one. The performance of opal primitives have also been measured to show the potential of building such a system over an existing microkernel.

Doubts/Issues:

1. Mentions about trying to extend the address space to a distributed system, but fails to understand the extent to which such a system could go (internet scale).
2. Most of the services in today’s world are modular and stateless (web services) and such stateless services have little interaction with each other and their modularity further reduces inter process communication, which contradicts the case of requiring excessive shared memory.
3. Does not mention about the potential cost of such large amount of memory, which is not even feasible in today’s world despite the available addressing capability in processors.
4. Being unable to change the virtual address of segments might lead to fragmentation in systems with smaller memory.

1. Summary
This paper talks about a system called opal and its main features like single shared virtual address space (64 bit) and protection domains. The design has full separation of addressing and protection. It talks about the advantages of sharing virtual memory, need of flexible protection structure (access control lists, capabilities) etc. It is designed on a MACH microkernel and has performance comparable with monolithic configuration and as secure as decomposed configuration.

2. Problem
Some basic problems with private address spaces (for each process) are the inefficiency in cooperation between protection domain (including translating to and from intermediate representation while copying data between virtual memory). Incremental updates, transfer of pointers are also difficult. At the same time putting all applications/component in the same process jeopardizes security/protection. By using using a single, shared virtual memory along with access control and capabilities, you can achieve high performance, scalability and security

3. Contributions
Main idea of the design is full separation of addressing and protection. It was built on wide address architecture(64 bit). Contiguous virtual pages (units of storage) are segments and units of execution are thread. The memory is shared among all threads, but each thread has a protection domain which restricts their access (using protection domains) to specific segments. It is easy to get/remove access to segments by simply calling attach and detach. Similarly it is easy to do interprocess communication using portals which are entry point to domain. The opal modules are statically linked, runtime address is fixed which makes it easy to share same physical copy of data, call procedure by knowing their address etc. Finally resource management is provided using resource group which can specify resource control policy, support bulk deletion (parent in-charge of child's resource too) and reference object (counter) to prevent early incorrect deletion of segment.

4. Evaluation
The evaluation of this system was done on an integrated software system "Boeing's aircraft CAD". The prototype was on a Mach microkernel. Performance (execution time) and scalability wise, the overlapping domain (opal uses this and shared memory) used in opal is comparable to a monolithic configuration and is as safe as decomposed configurations.(The prototype also preallocates, caches segments and domain)

They showed that read-only shared memory can be alternative to pipe. The paper also talks about few more performance loss factors that were caused because of being built as a MACH server (using separate translation map for each domain, need to be backed by external paging server etc)

5. Confusion
Was wondering did they have to justify the protection property of their system?
Would like to know more about password capabilities.

1. Summary
This paper talks about a system called opal and its main features like single shared virtual address space (64 bit) and protection domains. The design has full separation of addressing and protection. It talks about the advantages of sharing virtual memory, need of flexible protection structure (access control lists, capabilities) etc. It is designed on a MACH microkernel and has performance comparable with monolithic configuration and as secure as decomposed configuration.

2. Problem
Some basic problems with private address spaces (for each process) are the inefficiency in cooperation between protection domain (including translating to and from intermediate representation while copying data between virtual memory). Incremental updates, transfer of pointers are also difficult. At the same time putting all applications/component in the same process jeopardizes security/protection. By using using a single, shared virtual memory along with access control and capabilities, you can achieve high performance, scalability and security

3. Contributions
Main idea of the design is full separation of addressing and protection. It was built on wide address architecture(64 bit). Contiguous virtual pages (units of storage) are segments and units of execution are thread. The memory is shared among all threads, but each thread has a protection domain which restricts their access (using protection domains) to specific segments. It is easy to get/remove access to segments by simply calling attach and detach. Similarly it is easy to do interprocess communication using portals which are entry point to domain. The opal modules are statically linked, runtime address is fixed which makes it easy to share same physical copy of data, call procedure by knowing their address etc. Finally resource management is provided using resource group which can specify resource control policy, support bulk deletion (parent in-charge of child's resource too) and reference object (counter) to prevent early incorrect deletion of segment.

4. Evaluation
The evaluation of this system was done on an integrated software system "Boeing's aircraft CAD". The prototype was on a Mach microkernel. Performance (execution time) and scalability wise, the overlapping domain (opal uses this and shared memory) used in opal is comparable to a monolithic configuration and is as safe as decomposed configurations.(The prototype also preallocates, caches segments and domain)

They showed that read-only shared memory can be alternative to pipe. The paper also talks about few more performance loss factors that were caused because of being built as a MACH server (using separate translation map for each domain, need to be backed by external paging server etc)

5. Confusion
Was wondering did they have to justify the protection property of their system?
Would like to know more about password capabilities.

summary~
This paper presents a single shared address space system opal, and compare it with the current private address space system. The authors made the argument that the single address space will make resources sharing easier and provide better performance without sacrificing security by separating addressing from protection.

problem~
The private address space system provide each program a sufficient large address pool by letting each program has its own virtual address space so that addresses can be reused. Alone with this the private address space system also brings the benefits of isolation and protection. But these separate address spaces also imposes difficulties on data sharing and RPC. As the time the paper was written, the data sharing mechanism between processes and RPC protocol in the private address system is not flexible enough to dealing with the emerging large software systems that heavily depend on RPC and utilize pointer rich data structure.

contributions~
This work presents that idea that addressing and protection can be separated and develops several key primitives that enables this separation of addressing and protection in the single shared address space. These primitives include protection domain, which provides the access control of the basic storage unit called segment. Portal, which controls the RPC. Resource group, which deals with allocation and reclaiming of resources. With these primitives, majority of the UNIX services can be mimicked.

evaluation~
The authors implemented a prototype of Opal on the Mach microkernel. This prototype was tested under a real world large software system that has many components access and modify huge amount of shared data stored in the pointer rich data structure. The result showing the new organization made possible by Opal outperform the organization in UNIX system. But the work didn't provide much information about the protection to justify their argument.

confusion~
The part of linking really confuses me. I’m not sure about how the linker figure out the what virtual address it should assign to each of the instructions. Since the address space is sharing by other programs, the linker needs to know which addresses has been assigned and which addresses are still available. Will the linker have a complete history of what address it gave out previously.

1. Summary
The paper designs and implements an operating system with a single global address space on 64 bit wide architectures. This allows easier and faster sharing of data between processes by decoupling protection and addressing of both memory and persistent storage. A prototype of this operating system has been constructed on top of the Mach kernel for evaluation purposes.
2. Problem
The problem revolved around the lack of efficient data sharing mechanisms that did not need unnecessary copying of data or I/O to the persistent backing store. These mechanisms were required to improve the performance and reliability of complex co-operating applications working on large shared data structures. A solution with a system wide global view of memory was not previously feasible as previously machines had 32 bit addresses which could not access memory wide enough to allow this.
3. Contributions
The authors solution to this problem was to build a system wide virtual address space that would facilitate easy exchange of information as any pointer to data would be globally addressable using the hardware’s 64 bit address bus. To address protection concerns, a new implementation of a process/collection of threads known as Protection Domain (PD) was introduced. Each PD had access to certain modules (linked procedures) and segments (contiguous virtual space extents). A capability defined how one PD could access the contents of another PD. This allowed one PD to attach another PD’s memory segments as part of its memory image after checking the requisite permissions and then accessing this memory without making an unnecessary copy. This effectively decoupled memory protection and addressing with all memory being addressable but only being accessible after verifying the permissions. This design also relied on language frameworks/applications to implement fine grained protection using the above framework with the Operating System only enforcing coarse protection boundaries around processes.
4. Evaluation
The authors built a prototype Opal server on top of the Mach kernel. They also built mediators to allow information exchange with rich structures. The performance of various mediator designs with respect to PD boundary was shown to establish a tradeoff between high sharing and performance vs process protection. The authors also compare the cost of basic Opal calls such as creating/destroying a PD or segment versus the unix equivalents to show that the cost of the Opal calls are not significantly worse. However, they expect that with sufficient tuning an application will perform better on an Opal system. This is not validated with any test results with real world applications and without these there is no guarantee that new bottlenecks may not exist in this design that may throttle application performance.
5. Confusion
My primary confusion is how persistence is managed in this system, there are numerous references to addresses being stored in memory due to the global view of data. However this view may change between reboots and hence actual data (not the pointers) need to be placed in persistent storage. The paper does not provide any details on how and when the backing store is synchronized with its requisite segments and with other segments whose addresses may be present in said segment.

1. Summary
This paper is about resolving the tradeoffs between protection, performance and integration by reevaluating current operating system with the introduction of Opal which is a single/global address space system to support complex applications on wide-address architectures with isolated addressing and protection mechanisms.
2. Problem
The authors believe that while private address space systems increase the amount of addresses available to each program with ease in protection and cleanup mechanisms, these also present obstacles to efficient communication between application components. Due to hard protection boundaries imposed on memory, these systems fail to share and store pointer based information easily. And hence, authors suggest that with the advent of vast 64 bit addressing in wide address architectures, need to reuse addresses in the traditional systems could be eliminated.
3. Contributions
This paper primarily contributes to the fact that 64 bit address space is very large and such space could be exploited by removing the overhead of maintaining per process context state of memory to improve sharing and performance of complex, co-operating components operating over huge persistent data structures. Sharing could take place in the form of shared memory between threads of different domains was particularly significant. This makes memory protection cheaper and easier to use by separating program execution from resource management. Independence of protection and addressing lead to flexibility. Furthermore, extra layer of address translation otherwise imposed by address re-usage is eliminated. Such addressing mechanisms could be extended from a single node to include network wide persistent and inactive data in workstation clutter. This research work further points to optimizations in database systems for efficient retrieval with creation of views, caching of information and simultaneous multithreading. Another inspiration could be thought of as the new programming paradigm like MapReduce which allows for massive scalability on a cluster with parallel, distributed algorithm.
4. Evaluation
Authors attempt to evaluate their solution by implementing an Opal prototype on top of Mach 3.0 microkernel system with three major components viz. basic system abstractions, standard runtime package and a set of custom linking utilities. With this implementation Opal can co-exist with Unix implementation for bootstrapping and debugging purposes. Authors were able to prove that with overlapping organization of tree indexing program, Opal was able to retained both safety and performance features compared to monolithic systems. Authors also report that certain Opal operations like creation of segment, destruction of protection domain took more time. Since Opal was implemented over a kernel which favors private address space environment, there was a performance loss during certain kernel-specific operations and there could have been better evaluation in case of complete standalone kernel implementation.
5. Confusion
How does the sharing work across network with co-operating processes executing on Opal and on private address space system respectively? Was it really compatible towards other known systems at that time?

Summary
In a conventional OS, each process has its own address space. This paper is about a Single-Address Space Operating System by keeping a minimalist Opal kernel which handles the global view of memory. The authors present the implementation of protection and sharing in this system by explaining the modified linking and execution phases of code.

Problem
This paper emphasizes that protection and sharing of data are orthogonal to each other and should be treated independently. Conventional OSs allow private virtual address spaces for each process to ensure protection. The sharing implemented in this case by means of IPC or shared memory (by means of pointers) is inefficient, and impedes the performance of cooperating applications which manipulate shared data. Moreover, the authors say that the use of separate 32-bit virtual addresses was also to facilitate reuse of resources, but with wide 64-bit architecture, this is no longer a problem, and a single address space will suffice.

Contribution
One of the key contributions of this paper is the problem they identified: Addressing and Protection are not dependent. They show that by means of protection domains and segments, protection is maintained while maintaining ease of data sharing (by means of overlapping segments). They also use password capabilities to ensure secure access to segments. Another key instance taken is the view of a single persistent memory. Virtual address serves as an abstraction for physical + disk memory. The OS can even backup segments to non-volatile storage. This view can be of importance in database systems, or systems which share a single resource. The use of RPC and portals for communicating can also help in a distributed implementation of the system. With a single address space, lots of things change: Address resolution, protection, creating child processes, positioning of code in the only address space etc. The authors show that code positioning is not coupled with private address spaces and can be achieved using register relative addressing. One other benefit of this implementation is that virtual caches can be used, and cache access time is significantly reduced since virtual to physical translation before cache access is avoided.

Evaluation
One of the key aims the authors wanted to prove was that such a system is implementable, can coexist with Unix, and is comparable in performance to existing systems. For this reason, they implement the Opal kernel on top of Mach. The initial graph obtained on running the tree indexing program is promising as it shows Opal approach gives the performance of monolithic implementation and with better protection. But most of the latency results quoted are not of the stand-alone implementations discussed in the paper, and are bloated. Such standalone implementations of SASOS have been done after this work.

Confusion

Where does Opal stand on the spectrum of commercial OSs, which run all sorts of applications, and not only integrated SW like CAD. It seems in this system, a standalone process would take unnecessary time in setting up the segments, capabilities and talking to Opal kernel (as mentioned in Sec 5.3), all of which may not be needed.
How does Opal scale to distributed systems? Is this the reason they have used RPC for communication between different parts of OS? For example, to request a segment Opal kernel is contacted by RPC, whereas normal IPC could have been used. It seems counter-intuitive that they use RPC for communication after removing IPC and shared memory for data sharing.
Isn’t a 64-bit address space, and would result in sparse data allocation. How does the OS handle the extremely large global page table for 64-bit address space?

1. Summary
This paper describes Opal, an operating system designed for wide address (64-bit) architectures which decouples protection from addressing. Threads execute in a single shared virtual address space within protected domains.

2. Problem
Systems using Private-Addresses force a tradeoff between protection and performance for applications sharing data. Pointers do not have any meaning beyond the context of a process. As a result, sharing requires copying data between two private virtual memory areas, typically involving conversion from a neutral intermediate representation. As a result an application designer has to sacrifice performance in order to force protection. The authors are targeting a growing class of application which are composed of groups of programs cooperating through a shared pointer rich database. With the advent of 64 bit architecture, they are trying to explore the possibility whether such expensive sharing mechanism could be avoided by placing all the processes in a single shared virtual address space while providing the same level of protection and convenience of a private address space system.

3. Contribution
This paper aims to develop a single shared virtual address system. The main contribution was to define the abstractions and mechanisms used to develop such a system. By using the concepts of segment, protection domain and providing methods to attaching and detaching a segment, the authors show that one can develop such a system without compromising on protection. In order to facilitate a domain to be called by other domains in a protected and controlled manner, they introduce the notion of portal. A thread entering a domain through a portal execute code at a specific global virtual address ensuring that a creator of a portal can control what code is executed in a domain. This provides added flexibility to a system such as providing Unix like fork capabilities. The authors provide an evaluation of an implementation of Opel by Boeing's High Performance Design group for the next generation CAD systems. They also discuss the possible issues with a shared virtual address system like Virtual Contiguity, Conservation of Address Space and Copy On Write.

4. Evaluation
1. This systems adheres to the principle of a “Pointer being a Pointer”. Data sharing is as simple as in a shared memory multi core system. This leads to significant performance improvement as unnecessary data marshaling and possibly data transfer (in some cases) could be avoided.
2. However, passing pointers to share data may lead to coherency issue. Passing on this burden on Application developer could make software development difficult.
3. It is difficult to imagine such a system being scalable across a small network of nodes. I feel the issue of address contiguity would be especially exposed in large networks.
4. I feel the authors should have talked about other applications like the Boeing software where such a system could be of benefit.

5. Questions
1. Could we discuss the mechanism of program cleanup in multiple-address-space approach vs Single Address Space Approach? Why does the author say that cleanup is no harder in a single address space for “conventional” programs that do not share data or rather no easier in private address spaces for programs that do share data?
2. Does bringing persistent storage under the purview of Virtual Addresses have any impact on the notion of file system.
3. The authors discuss a very specific use case for Opal. What are the other applications that can benefit from such a system?

1. Summary

The paper presents the design of a 64 bit operating system (OPAL) which has a single address space for all the processes. This is different from operating systems like Unix where each process has a separate virtual address space and thus needs to maintain its own page table. The main idea for designing a OS with a single address space is to facilitate easy sharing of data between processes, without going through the performance overhead of using pipes or messages. Each thread/process when executing has the access to particular segments of memory determined by the protection domain. The paper explains the features of the OPAL model for sharing and protection , presents the systems and its abstractions, and evaluates the performance of the prototype of the design.

2. Problem

64-bit address space architectures leads to a large amount of address space available to the operating system and applications. The goal of the authors was to make use of 64 bit addressing to restructure OS to enhance sharing of data and simplifying integration of data between processes. The target application domain was integrated software environments for engineering design with shared pointer rich data structures. The problem the authors are trying to solve through OPAL is to achieve performance in sharing data, as well as ensuring protection and integration, by developing abstractions in the operating system.

3. Contributions

The main contribution of the paper is the idea of 64-bit operating systems with a single address-space to share data efficiently between processes and also enable protection at the same time. The disadvantage of isolating processes in separate address space is the difficulty in efficient cooperation by sharing data. There advantages of different address spaces being increased virtual address space for programs,hard protection boundaries and easy cleanup upon termination. Copying linearized data through a pipe or file incurs costs to copy, process and store the redundant data. On the other hand, placing multiple components in the same process avoids copying of data. However the notion of protection is lost, as one component of the process may interfere with the other components in the same process. In the single address model, the system coordinates the address bindings rather than the applications, leading to judicious sharing of virtual memory. The memory segments of each process are guarded by protection domain fields for protection of data. Access to a page is only allowed if the process is authorized by the capability object of the protection domain. Opal allows multiple domains to have overlapped memory segments and thus facilitates sharing. Opal also provides system calls to add or remove segments for sharing from domains. Opal does not have the notion of conventional programs, all code resides as procedures in the shared memory. In a single address space, linking phase of compilers will need to use global addresses for mapping symbols and private data, and is thus pretty complicated. Linkers need to replace memory references in code to a base+offset address in global memory to bind objects to addresses. Opal OS only performs storage allocation and protection at a coarser level. The finer details will need to be handled by languages at compiler level through memory allocation. Opal supports inter-domain communication through a remote procedure calls. Stubs for RPC bindings are generated for each process during initialization, which will however slow down the performance of a stand-alone program not using any sharing of data.

4. Evaluation

Opal prototype is implemented on top of Mach 3.0 microkernel and supports basic system abstractions of segments, protection domains, portals and resource groups, runtime packages for C++ like user mode threads,RPC proxy and heap management, along with custom utilities for linking code to execute at address in virtual address space. The implementation also shows that Opal can co-exist with another OS on top of a micro-kernel apart from the proof of the idea. The implementation can been applied to the Boeing's CAD system which represents data organized as a shared databases to be processed by various processes. A graph of execution of a tree indexing program is presented for three cases: decomposed, monolithic and overlapping. The monolithic setting does all computation in a single process sacrificing protection. Decomposed setting sacrifices performance but achieves protection by running producer and consumer in separate Unix processes. Overlapping setting is corresponding to Opal domains with data being shared, ensuring protection and the performance is also comparable to the the monolithic setting.

5. Confusion

Is OPAL is a micro-kernel?
how exactly is the linking phase done in a single address space?
How is shared memory implemented in UNIX? According to the paper it looks like shared memory is faster than communicating with pipes/messages/files. Is it true?

1. Summary
The paper discusses about Opal - single address space model which separates the concern for memory protection and memory addressability using the larger address space available on a 64 bit hardware. It also discusses how their design can improve performance of applications (with growing demands for inter process communication).
2. Problem
Lack of alternatives to existing mechanisms which duplicated data (to ensure protection) during interprocess communication thereby having a tradeoff on performance. The availability of 64 bit hardware was also not fully utilized since 32 bit address based global address space could access only 4GB.
3. Contributions
The authors utilized the advances in hardware support to address the issue by constructing Single Address space and separating the concern of protection by providing mechanisms in the form of protected domains (PD) - which depend on set of access rules in form of capabilities defined on them. PD(s) are constructed from subunits - segments which can be shared directly between processes by ‘attach’ and ‘detach’ mechanisms. By allowing direct sharing through calls to portals on these PDs instead of intermediate data structures such as temporary files, they are able to address the performance concerns. By providing the mechanism of capabilities, they are able to address security concerns.
This design allowed support for safe languages and yet leverage the benefits of global sharing. Yet, at the same time, they ensured efficient management of resources through resource groups and reference counts which arise due to processes’ mishandling of data.
4. Evaluation
They built Opal on top of Mach architecture and measured the time for specific tasks (e.g., creating domain from scratch) which were performing no worse than corresponding UNIX calls. They also listed out few applications, their shortcomings in their current design and how Opal can possibly improve the time, however no experiments were done to prove them in a concrete way. They also implemented utilities such as ‘mediators’ which massage data and proved how it provides best of both worlds (monolithic and decomposed).
5. Confusion
The paper doesn’t discuss the reason why the idea was not implemented completely, either due to lack of time or other external limitations in idea. Also, why we do not see any existing OS which implements this, thereby questioning the feasibility of such approach.

1. summary
This paper is about the abstractions, mechanisms and implementation of a single address space operating system in a 64-bit architecture which can support modular data sharing and protection for applications that manipulate pointer rich data structures regularly.

2. Problem
One of the major problems of having processes run in separate private address spaces is that the scope for efficient sharing of data using pointers between the processes is significantly reduced as the pointers need to be converted to a common intermediate representation before they can be shared with a process in another address space.This forces application designers to make a trade off between performance and security.

3. Contributions
The key contributions of this paper are the decoupling of protection(using protection domains) from program execution(using RPC), resource handling(using portals and resource groups) and virtual storage(using segments).Additionally in the Opal prototype virtual addresses are context independent and always refer to the same data.

The segment is the unit of storage allocation and protection , the unit of execution is a thread and a protection domain is the context for a thread which restricting the thread's access to a set of segments.Security and protection is made possible through capabilities which are 256-bit value that give permission to access an object(like a segment or protection domain)in a specific way.

Communication between threads in different protection domains is through portals.A domain can create a portal through which other domains may call it in a protected manner.The portal ID is part of the 256-bit capability value mentioned earlier. A thread can create a child domain and execute code in that domain by registering a portal for the child and calling a procedure through that.

Reference counts are used as a mechanism to manage resources whereby a reference count represents the number of entities that are interested in a resource. Resource groups are used to facilitate bulk deletes of unclaimed resources.

The prototype has been implemented on top of the Mach 3.0 microkernel. This approach has been followed for convenience and to allow Opal to coexist with Unix thus allowing it to make use of Unix utilities to bootstrap , monitor and debug.

4. Evaluation
The authors have evaluated the prototype in Boeing's CAD environment which uses a central database to store geometric information about aircraft parts.A framework based on mediators has been implemented to facilitate tools to update objects incrementally without being obstructed by inter tool output and input dependency complexities.Through measurements and graphs the authors have shown that there is an increase in performance for an Opal application that arises from sharing memory.This measurement has been taken over a monolithic , decomposed and overlapping protection configuration. Additionally, the performance of Opal primitives have been used to demonstrate that it is possible to build a single address space operating system on top of conventional kernel with competitive performance measurements.

5. Confusion
The topic of password capabilities is brief and not very clear.Also , If there are multiple threads in a domain , and each thread has a private version of writable static data how do we prevent the threads from interfering with each other's copy of the data since they are all in the same domain ?

1. summary
This paper is about the abstractions, mechanisms and implementation of a single address space operating system in a 64-bit architecture which can support modular data sharing and protection for applications that manipulate pointer rich data structures regularly.

2. Problem
One of the major problems of having processes run in separate private address spaces is that the scope for efficient sharing of data using pointers between the processes is significantly reduced as the pointers need to be converted to a common intermediate representation before they can be shared with a process in another address space.This forces application designers to make a trade off between performance and security.

3. Contributions
The key contributions of this paper are the decoupling of protection(using protection domains) from program execution(using RPC), resource handling(using portals and resource groups) and virtual storage(using segments).Additionally in the Opal prototype virtual addresses are context independent and always refer to the same data.

The segment is the unit of storage allocation and protection , the unit of execution is a thread and a protection domain is the context for a thread which restricting the thread's access to a set of segments.Security and protection is made possible through capabilities which are 256-bit value that give permission to access an object(like a segment or protection domain)in a specific way.

Communication between threads in different protection domains is through portals.A domain can create a portal through which other domains may call it in a protected manner.The portal ID is part of the 256-bit capability value mentioned earlier. A thread can create a child domain and execute code in that domain by registering a portal for the child and calling a procedure through that.

Reference counts are used as a mechanism to manage resources whereby a reference count represents the number of entities that are interested in a resource. Resource groups are used to facilitate bulk deletes of unclaimed resources.

The prototype has been implemented on top of the Mach 3.0 microkernel. This approach has been followed for convenience and to allow Opal to coexist with Unix thus allowing it to make use of Unix utilities to bootstrap , monitor and debug.

4. Evaluation
The authors have evaluated the prototype in Boeing's CAD environment which uses a central database to store geometric information about aircraft parts.A framework based on mediators has been implemented to facilitate tools to update objects incrementally without being obstructed by inter tool output and input dependency complexities.Through measurements and graphs the authors have shown that there is an increase in performance for an Opal application that arises from sharing memory.This measurement has been taken over a monolithic , decomposed and overlapping protection configuration. Additionally, the performance of Opal primitives have been used to demonstrate that it is possible to build a single address space operating system on top of conventional kernel with competitive performance measurements.

5. Confusion
The topic of password capabilities is brief and not very clear.Also , If there are multiple threads in a domain , and each thread has a private version of writable static data how do we prevent the threads from interfering with each other's copy of the data since they are all in the same domain ?

1. Summary
The authors describe the various abstractions and features of Opal, a single-address-space OS tailored especially for integrated software applications running on 64-bit architectures. The authors claim that Opal achieves easy memory sharing without loss of protection via the use of a global address space. A prototype has been built on an existing microkernel and the results suggest that their OS is as safe as a decomposed configuration and almost as fast as a monolithic configuration.

2. Problem
In a 32-bit architecture there is a need for address reuse via private virtual address spaces as it is scare. Address reuse leads to inefficient sharing of memory (via data copy), forces the application designer to choose between protection or performance and pointer sharing requires prior coordination, which is quite limiting as the sharing patterns must be known beforehand. However, with the introduction of 64-bit architectures, the authors claim that address space is no longer a scare resource and they use this to simplify memory sharing without loss of protection.

3. Contributions
The main idea of Opal is to decouple addressing from protection. Anyone can reference a page but may not have the required permissions to access it. The units of storage allocation are contiguous virtual pages known as segments that cannot grow. Protection domains are the execution context for threads. These domains specify the segments that can be accessed by the threads while they are a part of the domain. Access control is achieved via the use of password capabilities. The threads have the capability to attach or detach segments during execution to allow or deny direct access. Opal defines portals as entry points to domains via which control transfer can occur. The protection domain specifies the starting address for execution when threads enter it via a portal which let’s the domain have control over what code is executed within it. Opal also introduces the concept of creation of child protection domains to protect the parent’s data from an untrusted subprogram. Handling private static data in Opal is not as straightforward as it is in conventional systems. In order to ensure that the private static data use different locations, the code uses relative addressing. Coarse-grained resource management is provided via resource groups that allow bulk deletes of unclaimed resources and via reference objects that prevent untrusting entities to reduce the resource references.

4. Evaluation
In order to test the OS described, the authors built a prototype of Opal on top of Mach 3.0 microkernel. This also brings home the fact that Opal can co-exist with other environments on top of a microkernel. The graph depicting the execution time of a tree-indexing program confirms that Opal is as safe as a decomposed configuration and nearly as fast as a monolithic configuration. The authors then present the time taken to execute various Opal primitives. These results are not totally right as they also include the overheads that arise due to the underlying microkernel. It would have been better if these numbers were recorded on an independent version of Opal.

5. Confusion
I did not quite understand how password capabilities function. It would be great if this could be discussed in class. Also, I am not totally sure how Opal isolates private static data among threads of the same domain. Wouldn’t this be an issue if we wouldn’t want a thread to access private static data of another thread in the same domain? In such a scenario, would the threads cease to exist in the same domain?

1. summary
The paper introduces Opal, a single address space OS, which is shared amongst all processes. The authors believe that private address spaces are not efficient when it comes to sharing and moving to the 64-bit addressing, so they propose that the system should contain only one address space to be shared by all processes.
2. Problem
When the paper was written, systems were slowly moving from 32-bit to 64-bit addressing. With this increase in the address space capacity, the authors believed that a new strategy for addressing and to use memory was needed. In addition, the authors argued that sharing between processes is slow on traditional private address space systems because some IPC mechanisms constantly copy data over from one address space to another.
3. Contributions
As a result, the authors propose Opal, a system that has only one address space, which is shared by all processes. At first glance, this helps greatly with sharing because data does not have to be copied from one address space to another for IPC. Rather, a process just needs to notify the other process of the address where the data resides. Consequently, the other process can simply access the data, without any need for a copy operation. Of course, this raises the problem of security and protection. Without protection, any process can read (and write!) other processes’ data since everything is in one address space. Opal’s protection abstraction is defined by protection domains which define access rights for threads running in that domain. As a result, each protection domain has certain access rights for certain segments of the address space. These access rights are checked when an address is used by a process to ensure the process has in fact the permissions to access that data segment.
The authors made a prototype on top of the Mach microkernel and used the CAD system, which consists of multiple highly interactive processes, to measure the prototype’s performance. They even compare fork performance of Opal against traditional Unix systems, where the performance of the two systems are very close.
4. Evaluation
When it comes to allocation, the authors simply say, we just allocate from where we allocated last and keep going towards the end of the address space, and since the address space is so big (because of 64-bit addressing), we will rarely have to recycle through to reallocate freed segments. However, they have to accept that many systems (especially with big-data applications) will end up running for a while that eventually the entire address space is used, but the authors did not test this situation to see how well their “recycling” algorithm, which is not explained in detail, performs.

In addition, the Opal server on top of the Microkernel is just a prototype, but I feel like it might be best to keep the system like that instead of making Opal the only option. As a result, legacy code could continue to run on the system and they can be eventually ported to the Opal single address space world if the application developers desired or saw a benefit. However, the authors made it clear that this is just a prototype and in reality Opal will be its own OS.
5. Confusion
How the capabilities/protection domains were used to enforce protection was not clear to me.

1. Summary

In this article, the authors describe a system which does not use virtual memory, but in which two pointers with the same value always refer to the same memory location, even when those pointers are located in different programs. To provide for the security features of virtual memory, they use a new concept of protection domains.

2. Problem

The primary problem that the authors address is difficult communication between processes that interact with each other a lot. In several applications, a program would have to read an entire database since the addresses for the data the program used were relative to that database, rather than a part of the operating system. In addition, the maintenance of virtual memory slows the operating system down, in a way that the authors considered unnecessary with the larger memory capacities then newly available.

3. Contributions

The paper contributes a distinction between addressability and access, allowing programs to know addresses for memory locations which they are forbidden to access. This is implemented using capabilities, which grant permissions for each system resource. In addition, the paper contributes an implementation of their system, built on top of the Mach microkernel.

4. Evaluation

The authors evaluate this implementation in two different ways. They measured the running time of an application consisting of three threads, two of which maintain different indexes of the same collection of records. They ran this application on their system in three different ways: one way simulated running the application in a single Unix process, another running it in three processes, and the third running it using the full capabilities of their implementation. While this seems an appropriate test, it would have been more rigorous to compare the running time on their implementation to the running time on an actual Unix system. They also measured the time taken by various individual primitive operations in their system. They compared this with analogous operations in Unix and found it to have comparable or slightly improved performance.

5. Confusion

The primary thing I found confusing about from this paper was the access control mechanism. It is not clear how a resource's capability is used to actually check whether the access to that resource is permitted. It also is not clear how attaching extends that mechanism.

1. summary
This paper describe what is the main advantage of single address space system, what elements are considered to build it, how it is implemented. The Opal provides flexible shared memory address among programs without performance penalties

2. Problem
Requisite address space is increasing by double each year and current 32bit address space is not enough to satisfy the demand of address extension.
Opposed to single address space, multiple(private) address space has a disadvantage related to memory protection and sharing which is protected from and shared by pointer because the data to be shared need to be transmitted through private virtual space.
Strong protection comes at the sacrifices of performance because it needs the interaction between a system and an application to keep the protected area from another harmful applications.

3. Contributions
Opal provides shared memory address between processes to distinguish protection area and sharing area. The address space is allocated and controlled by system and it provides the shared memory and protection to programs using the single address space(SAS).
Opal has several policies for protection and sharing supported by coarse/fine grained method, access control attaching/detaching a segment to access control lists, and interdomain communication by shared memory with a portal which is a entry point to a domain. In addition to these, it provides protection domain with protected procedure call through portals. Opal can make it possible to assign the start point of program with different addresses to each programs while the start address is fixed to each programs in conventional system. Resource management and reclamation in Opal use explicit reference counting when the resources are attached or detached from user software.
Opal is implemented on 32bit system coexisted with UNIX system to use utilities in UNIX. The primitives is handled by Opal server and Opal segments is back by Mach paging server.

4. Evaluation
The mediator in Opal to use resources efficiently for CAD tools is evaluated to see the performance improvement. Among three cases, the Monolithic sharing a protection domains, Decomposed using two overlapping domains and and Overlapping arbitrating the transaction with RPT by mediator, are evaluated and the Overlapping showed the best result in terms of performance along with safety.

5. Confusion
Why each threads has their own virtual address is they don’t want to use physical address effectively. I think the method proposed in this paper makes the virtual address space to be fragmented.

1. Summary
The paper describes the design and implementation of a single-address-space Operating System - Opal. Such an approach is facilitated by advent of 64-bit address spaces which eliminates the need to re-use addresses. The aim of this experiment then, is to explore the strengths and weaknesses of the single-address-space approach with respect to the traditional approach of having separate virtual-address spaces for each running program.

2. Problem
The traditional approach of isolating programs within their own private spaces for protection presents various problems with regards to inter-process communications. Using pipes or sockets for communication can lead to overheads for copying and storing redundant data. The shared memory facilities(like mmap) provided by these traditional operating systems can reduce the copy and storage overheads but they still do not present an elegant solution to share pointers across the virtual address-spaces.

A tightly integrated application with various components can then be designed to run components in different processes that exchange data, which can lead to poor performance, or in a single process by sacrificing protection. These systems therefore force tightly integrated applications to make a trade off between performance vs protection.

3. Contributions
The goal was to build an Operating System which has a single shared virtual-address space for all running programs, and the main contribution of this work was to define the fundamental abstractions and mechanisms which can be used to build such a system.

Segments were the new units for storage allocation and Threads were the new units of execution, a completely new abstraction called Protection Domain was used to restrict the threads to only access specific segments. These abstractions decoupled addressing from protection allowing more flexible data sharing across Threads.

A new abstraction called Portal was designed to share data and transfer control between Threads and Protection Domains. Threads can call into the portal which has an associated Protection Domain and an entry point which can be the target code, such a call will transfer the control to the target code running in the protected environment. This programming construct can be used by Parent Threads to spawn new Threads(which are effectively new programs) and set up RPC connections between siblings or cooperating domains.

Opal also addresses the problem of using private static data in a single-address-space system where multiple modules can be loaded concurrently. Such concurrent instances can share the module's code but to allow concurrent execution they must maintain the private data at separate virtual memory per the execution stream and it is achieved in Opal by using register relative addressing with base register values assigned dynamically.

Apart from the above contributions Opal uses resource management techniques which provide - protected reference count for objects in shared segments so that untrusted threads cannot release more counts than it requested and mechanisms for accounting and bulk deleting of unclaimed resources.

4. Evaluation
The main objective of the authors was to explore the strengths and weakness of single-address-space system relative to a traditional system and to that end they have listed certain trade offs in the Opal system like: Virtual Contiguity which can affect programs with huge indexed memory structures, this problem arises due to the fact that segments cannot grow and that segments allocated at different times may not necessarily be contiguous in the virtual address space. And Address Space conservation because now the virtual memory is managed as a global system resource.

The Opal system was designed to run on Mach micro-kernel and whatever little performance measurements were done are not enough to prove that Opal will perform better than a traditional operating system under different types of loads, so the benchmarking and performance evaluation of this system leaves a lot to be desired.

5. Confusion
Is it feasible to run this OS on a server in a modern data center where people can deploy or delete applications whenever they want?
Where can such an OS be used today, are there any deployments we can talk about?

Summary:
This paper describes the design of a single virtual address space operating system -Opal. With the advent of 64-bit addressable architectures, Opal advocates using a single address space for all programs and persistent storage. It describes the radically different idea of decoupling protection from addressing.

Problem:
The larger problem really is how to balance sharing vs having protection for each thread in a large software system. The conventional OS abstractions that provided protection automatically ruled out direct sharing. Even though shared memory was supported in some form, general data structures couldn’t be shared directly because pointers have no meaning across address spaces. A similar problem exists in code sharing which may need some dynamic linking or message based approach.

Original Contributions
The main idea was to put all of the user-space programs in a single virtual address space, and decouple protection of this memory using a new abstraction called protection domains. The memory was allocated in segments and a protection domain gave a list of segments accessible in that domain. The single address space allowed pointer rich data structures to be used without any conversion.The memory segments could be dynamically attached or detached from threads,and the capability to do so could be shared among processes.

One of the cool new abstractions was that of the portal, which would let a thread execute code from a different domain by literally changing into the target code’s protection domain. In effect its really like executing a remote procedure call by jumping to that specific procedure, which was great.

Opal had the facility to mark segments as persistent so it could map persistent storage into the virtual address space however those mappings were permanent even across reboots. And lastly for reclamation of resources Opal kind of tries to export that functionality to the user space - typically the run-time system. The OS simply maintains reference counts and can do that in groups (reference objects) so independent set of processes do not interfere, but it doesn’t really provide automatic clean-up.

Criticisms:
One of the positive points is that the system lends itself naturally to multi-threading that works with shared memory parallel hardware like multi core systems.

Some of the problems really are with the way modules have to be linked. Shared code could not have private static data at the same virtual address, so that has to be made offset based. Several modern architectures use a lot of PC relative addressing and have static data like literal pools, in a single virtual address space multiple processes cannot run the same code and all of it has to be made pointer based. This can have performance problems such as those commonly seen with virtual functions in C++.

Secondly, I do feel security is compromised. For example a bug in one of the user processes could leave open access to some protected resource, so programs were assumed to be trusted while designing Opal.

Questions:
The paper talks about asymmetric trusts relationships, so are there other ways to deal with it besides a shared virtual address space?
Message passing may be in-efficient from a latency perspective but they may do well in bandwidth, so is that a fair premise to reject the idea?

1. Summary
This article discusses the construction of Opal, a single-address-space (SAS) operating system. The basic principle is that all applications/processes share a single address space and subsequently all data within that space. All virtual addresses have a unique interpretation and are context-independent. The paper lays out a sketch of the system, describes its weaknesses and strengths, and does a brief comparison of other related systems.
2. Problem
Multi-address-space (MAS) systems, which allocate private virtual spaces for each process, force tradeoffs between protection, performance and integration. For systems designed around groups of programs that cooperate through a “shared pointer-rich database”, they are slow and unreliable. In contrast, SAS treats all virtual address space as a global resource, thus allowing easier sharing of pointers.
3. Contributions
Creates a system based around the following principles:
- Operating system protection structures are not the right level to impose modularity (276).
- Storage allocation, protection, and reclamation should be coarse-grained at the OS level. Fine-grained control is best provided at the language level by compilers and runtime systems (278).
- Do not dictate data management to languages, particularly the placement of capabilities and addresses (282).
- Desired features: flexible protection, simple shared memory, mapped persistent storage (289)
- Facilitating the sharing of a single copy of active data on each node (291)
Advantages:
- easier to structure user software as a group of cooperating domains with arbitrary sharing patterns and cross-domain RPC (280).
- threads in a module can share single physical copies even though they may be in different protection domains (281).
- procedure pointers can be passed and shared at system level.
- any thread can dynamically call and attach any accessible procedure.
An initial implementation was built over a Mach microkernel. Mach was designed for private-address spaces, and some native capabilities in Opal such as portals are not specified. In addition, Opal memory segments are potentially shareable, which requires them to be backed by an external paging server. This leads to further slowdown, but not an unacceptable level.
4. Evaluation
In the end, authors deem that their Opal implementation has performance that is “reasonable” and does not add significantly to the underlying Mach abstractions. A native Opal kernel is expected to have further improvements.
The example that they present for Opal use is that of the Boeing CAD and their pointer-rich system where sharing of data is essential. This seems like a very specific use-case, though, and not commonly encountered for the vast majority of systems. I am curious, though, if there are other reasons why this was never adapted for practical use today.
5. Confusion
While it sounds reasonable when laid out on paper, I am skeptical as to the logistics in practice. One thing that is particularly unclear is how “capabilities” are assigned. They are the main security mechanism in Opal, and from what I can tell, they work via a password-based system. So in order to access resources, do applications need a password for each individual capability? How adaptable is this mechanism?

Summary
This paper presents the design and implementation of Opal, a single-address-space operating system. It further details the strengths and weaknesses of using single address space systems. The focus is on sharing and protection of memory.

Problem
With the rise of 64-bit architectures(at that time), there arose a need to utilise the wide address space to it's full extent. Traditional operating systems, based on 32-bit architectures, faced shortage in address spaces which led to using private virtual address spaces for each process. For many of the integrated software environments, using private address spaces posed a performance vs protection tradeoff.

Contributions
Provides a working prototype of a single-address-space operating system, Opal, on top of a Mach 3.0 microkernel. It utilized the wide address capability of 64-bit architectures and provides a performance equivalent to a monolithic process without compromising safety. Opal provided a complete separation of protection from addressing in the form of threads(in this context, processes) running in a protection domain within a single-address-space. It made sharing of data easier among threads with the dynamic linking of segments(chunks of memory) to a thread as per it's need and thus provided a new effective way of inter-process communication. The shared segments would have additional capabilities field defined by it's owner thread in order to ensure safety.

As per the authors, this idea of a single global address space could also be extended to work for a small workstation cluster. The paper also comes up with some interesting performance analysis and gives a brief idea on it's comparable performance to the traditional operating systems with it's simplicity in the design of operating systems. One such performance analysis was done with Opal mediators running tree indexing programs. The good part about the paper is it also discusses about the challenges that would come up while implementing such an exokernel like virtual conguity and difficulties in having copy-on-write functionality.

Evaluation
Even if the prototype implemented here wasn't actually an ideal exokernel (as it was built on a Mach microkernel), the idea of single-space-address operating system looks promising for applications in the integration software environment with the performance results shown by the authors. Though, to have a final word on such a system, it makes more sense to have comprehensive testing with an actual exokernel and compare it with the traditional operating systems, which the paper misses to give out.

Confusion
Given the results shown by the authors, the idea seems plausible enough to me. But, I am not sure why this isn't much popular among modern 64-bit systems. Or to re-frame it, are there some other consequences too in using such a system apart from the ones mentioned in this paper ?