CS 736 - Spring 2007 - Paper Discussion

Summary:
The paper details the design and implementation of Opal, a single-address-space OS designed for wide-address architectures. A single address space can be used for code and data sharing as protection is made independent of addressing. This model offers increased performance over IPC between decomposed processes and better safety than a monolithic process where different processes are combined for performance.

Problem:
With architectures offering wide-addressing (64-bit), it is possible to envisage a single and very large address space over which processes can be run. This can be exploited to change the code and data sharing mechanisms in the current Unix like environments, where either safety or performance gets sacrificed.

Contributions:

Interesting usage of the huge address space made available by 64-bit systems to allow a system-wide single address space. The independence of protection and addressing by the use of protection domains makes code and data sharing gives the performance of a monolithic process without compromising safety.
The ability to attach and detach from a segment using named capabilities at run time is quite powerful, that is any procedure becomes accessible by knowing its address. This contrasts with conventional systems, in which "programs" cannot generally be called directly because they are linked to execute in a private address space. The early protection choices are locked in at static link time.
The whole IPC model is made unnecessary and the serialization of data to intermediate form to share between two processes is not required.
The comparison with the older Operating systems is interesting and the non-requirement of a single type-safe language to achieve protection and performance is attractive.

Flaws:
The IPC model is fairly easy to program for when compared to the shared memory model, as concurrency issues arise. Pipes are convenient, and if the processes are not tightly coupled, the added programming complexity of mutual exclusion may not be attractive.
The basic requirement of a wide-address space (64 bit) architecture is sketchy. 32-bit architecture is dominant even today, although 64-bit machines are becoming mainstream, so this becomes less of a problem.
The serialization argument over the network seems less convincing as the network/disk latency may be more of an issue rather than conversion from machine-dependent pointers to context-independent data structures. The security compromise also appears severe over the network. (The authentication costs may be high enough, as to not worry about serialization). The paper does not validate this as a performance issue over the network. Also the state maintainence over the network by caching and coordination for address spaces over multiple machines seems like a kludgy overhead.

Relevance:

The increasing popularity of 64-bit systems may be a case for a single-large addressing system or better still a hybrid one. The overall idea of having some shared memory domains transparently is quite attractive.

SUMMARY
In "Sharing and Protection in a Single Address Space Operating System" Chase at
al. explore advantages and disadvantages of single-address-space systems. The
focus is on sharing and protection. A prototype, Opal, was implemented.

--------------------------------------------------------------------------------

PROBLEM
Traditionally multiple virtual address spaces are used for different processes.
This simplifies issues of protection but complicates memory sharing and makes
it inefficient. Single-address-space systems simplify sharing but make protection
more challenging.

--------------------------------------------------------------------------------

CONTRIBUTIONS
* Implementation of Opal, a single-address-space OS

* Exposing limitations of separating processes with by means of virtual addresses.

* Decoupling protection and addressing mechanisms

* Concept of persistent distributed memory. Single address space makes memory
addresses "universally" unique

* Hierarchial protection domains using capabilities

--------------------------------------------------------------------------------

FLAWS
* The case for the need of single-address-space system should have been made a bit
more stronger. Otherwise casual readers may not agree with urgency of the matter.

* Scalability. Single address space requires a lot of resources to be utilized for
memory addressing. Even 64 bit addresses the authors used in the article may become
insufficient as technology progresses and especially since the authors envision
distributed (e.g. over a network) memory. The abstraction of a single memory address
may be too inflexible and inefficient (even if 64 bits will be enough to address
everything). Since memory is likely to remain relatively expensive (though per-bit
price goes does, demands of volume and performance grow) and heavily-used resource
single-address-memory may be too inefficient in a distributed system to be practical,
and work-arounds might be more attractive.

--------------------------------------------------------------------------------

RELEVANCE
Having a single-address-space is attractive in many specialized circumstances
(i.e. specific workload and performance requirements, though general-purpose
OSes are probably better off without it). The paper gives a nice overview of the
topic.

summary:
The paper talks about design details of Opal, which is a 64-bit, single-address-space operating system.

Problem:
Most of the operating systems at the time used (separate, virtual) address-space as a means for protection. This achieves protection easily, but makes sharing complicated and expensive in terms of performance. Opal was an attempt to separate out protection and address-space, making use of the recent (at the time) development of computer architectures with 64bit addressing.

Contributions:
- Creation of a single address space system and the idea of separating out protection and address-space are the biggest contributions in this paper. The paper describes a capable protection mechanism with the use of password capabilities, access control lists, portals, etc withough splitting the address space.
- The single address space allows easy sharing and direct access of data (including pointers and objects - which are not possible in traditional unix-like sharing with shared memory) and code.
- The concept of extending the single address-space to a small network of computers is radical.

Flaws:
- Managing persistence for segments seemed to be not well thought off. The document doesnt say much about crash and recovery in such system; it may end up in a journalled system for memory!! This becomes even more complicated when we talk about an address-space that spans multiple computers.
- The whole design is based on the fact '64-bit is a lot'. History tells us this is not true. Transition from 8bit to 16 bit to 32 bit computers happened in pretty much no time.

Relevance:
The ideas presented in the paper are interesting, and calls for a fresh look at the way traditional OS uses virtual addresses. In fact, VxWorks (a widely used RTOS) makes use of a lot of these concepts. I think it is better to get to a middle-ground: Still have virtual address as protection domains (as the paper says, it has many advantages in management and cleanup), still have processes and threads, but provide protection mechanisms between threads within a process. This gives us the best of both designs.

Summary
This paper presents the Opal operating system, which uses a single address space for all applications. This is enabled by 64 bit address spaces.

Problem
The primary problem addressed here is the issue of how programs can communicate and share data in a more efficient manner given the availability of 64-bit address spaces. Previously, it was necessary for each process to have a seperate virtual address space due to the 32-bit address space restriction. The requirement for seperate virtual address spaces makes interprocess communication much more difficult than if everything was addressable.

Contributions

• System which uses single address space for all applications
  
• The protection system for dealing with a single address space. The protection scheme discussed is quite flexible
  
• Significant discussion of the challenges associated with a single address space system
  

Flaws
I believe that exploiting the advantages of such a system would pose a significant challenge to application programmers because they are used to the old model (even though the old model sucks a great deal). Dealing with the increased flexibility, while very powerful could pose new challenges and problems.

Relevance
This idea is not yet in popular use and I don't think that the relevance can yet be evaluated. It will be interesting to see how 64-bit address spaces are exploited in widely-used systems.

Summary:
This paper introduces an operating system “Opal” which uses a single virtual address space to enable efficient, safety address based data/code sharing between several applications with flexible protection domain that will be implemented on 64-bit architecture focusing on the concept and mechanism of memory sharing, protection, and implementation of a prototype.

Problem:
One of the reasons that current systems are using private/virtual address system is to provide enough addresses to multiple tasks and also provide safety. But this architecture had a poor inter process communication facilities. Since the 64-bit architecture has appeared and there are plenty of addresses available, it is not necessary to use a private, process based addressing and an operating system that encourages collaboration between tasks/applications with direct, straight forward addressing were possible alternative.

Contributions:
Single address space enables inter task/application communication without translation and is capable for efficient large scale collaboration in workstation or in a specified area network. And “segment-grained protection” including the usage of thread which is simple and minimum set of information comparing to process in Unix simplifies the capability management in the OS. Actually this is possible because the single-address-space enables sharing and specifying the address is possible. Also Opal provides flexible sharable protection domain and interface for configuring access rights for inter-domain communication such as portal.
I’m not sure if the evaluation was efficient but the way they had a prototype that fits into the case such as CAD was interesting and made me easier to understand.
Persistence and Distributed address enables to point directly to the segment on a separate computer and get rid of worrying about address changing at the remote site. But not many information are on the paper.
Not only discussing the aspects of Opal, this paper contains a fair amount of comparison and analysis of previous and current systems such as Unix, Pilot, and Multics that clarify the characteristic and positioning of Opal.

Flaws:
First of all, because the data accessing paradigm has changed dramatically in Opal, to fully utilize the strength of the system, an application programmer might have an extra cost to develop a program.
Next is about the address space allocation. Even though they have a huge 64-bit address space, I though there might be some chance to discuss a little more about allocation policy such as controlling the address space allocation so that an application could use the address contiguously for a long decade.
I think prototyping was very useful for demonstrating the characteristic of Opal, but it might be interesting if they had a system implemented from the kernel level to make an impact as an next generation OS.

Relevance:
Since 64-bit architecture becoming popular in home environments too, I think some potential usages of this system are hiding in our daily activities, not only industrial huge applications. Also, showing the possibility of utilizing 64-bit address space in simple mechanism was impressive. Like we already are using services that stores data in remote site and share many of them such as Google’s web applications, I agree sharing and distributed system will be a key of utilizing the 64-bit address space.

Summary;
The paper describes the philosophy and proof-of-concept implementation of Opal. It describes the idea of having a single address space OS where the notions of protection and addressing are split apart, and passing pointers to segments between procedures in order to share memory; it also covers their implementation built on the Mach microkernel.

Problem:
Current interfaces for IPC are slow or clunky. The authors were trying to create an environment that would make it easy to develop suites of programs that worked together using shared memory for IPC by allowing them to use raw pointers in the shared segment.

Contributions:
* Presents a semi-novel way of utilizing 64-bit address spaces
* More to the point, discusses a lot of the technical issues that a single address space machine would bring up, such as preserving the semantics of fork, making code that's properly relocatable, doing garbage reclamation, etc.
* I also really like how the authors give some time to discussing how you might actually implement applications in such a system with the managers

Flaws:
I'm slightly skeptical about the programmability of the system, and in particular the shared memory. In theory it sounds great, but my impression is that if you have something like a message passing system it's easier to get concurrent programs correct. Having memory shared between threads or processes introduces concurrency issues which means you have to deal with locks or non-blocking algorithms and structures, and it's not hard to find examples of programs getting this wrong. The authors' managers could probably help a lot to ease the difficulty, but if programs actually were built to use as much sharing as I think they foresee, I could see concurrency issues becoming a problem.

Somewhat related to that because it has to do with the programmability of the system, I think they were a little too dismissive of the proper semantics of fork. They said that there were two main purposes: creating concurrency, and allowing the parent to set state before exec. But they say that the first case would be better served with lightweight threads. I don't buy this. Separate processes do two things for the program that threads don't; they make it so there's no concurrency issue (because there is no shared state), and they make it so that if there is a bug that causes the child to crash (e.g. in a web server) the parent can keep running. If you take their suggestion and use threads, a bug would bring down the whole process. Their second reason is more convincing, but I would still be worried that you'd wind up with something like CreateProcess that tries (and probably fails) to include every bit of state that you might want to set in a child.

Relevance:
64-bit machines have just started to move in force into the consumer market over the last few months, so widespread 64-bit computing hasn't really happened. Thus the field is still theoretically open to ideas such as these.

Summary

This paper presents single address space operating system called Opal in order to make sharing of data more efficient. Sharing is optimized and simplified because addresses in a single address space are context independent while there is no loss in protection because right to access a segment is determined by protection domain in which a thread executes. The authors propose this solution for a 64-bit architecture since it provides a large enough address space to be shared among all the processes.
The paper presents the Opal model, various abstractions and mechanisms supported, provides experiences with integrated applications, and also discusses different issues involved with single address space operating system.

Problem Description

A multiple address space operating system presents obstacles to efficient cooperation between shared application components. The authors mention that in such systems, pointers have no meaning beyond the boundary of a process and sharing pointer based information is not easy. Secondly, the primary sharing mechanisms rely on copying data between private virtual memories. This is quite expensive in case of large and sparsely used data structures. In order to solve this problem, the authors suggest using a single address space operating system which treats all the virtual address space as a global resource controlled by the operating system.

Summary of Contributions

In this paper, the authors propose ‘Opal’ which provides a single global virtual address space shared by all the procedures and all the data. Authors propose a full separation of addressing and protection. In order to implement protection, the authors suggest a thread executes in a protection domain and that domain defines the access rights for that thread. By using the single global virtual address space, copying of data between private virtual memories is avoided which can prove to be quite expensive in case of a multiple address space system.
Opal also separates program execution, resource ownership and resource naming from protection domains. As a result, memory protection get cheaper, becomes easier to use and easier to change. The authors also extend the idea of single global address space and propose a single global address space for a small workstation cluster.
Opal also implements a garbage collector. Programs can request resources using ‘Attach’ and can give up the resource using ‘Detach’. ‘Attach’ increments a count while ‘Detach’ decrements that count. If the count goes to zero, Opal frees that resource. Secondly, if a program using a resource exits prematurely, resources acquired by it are freed by Opal.
This paper also discusses various issues involved with single global address space e.g. virtual contiguity, conservation of address space, supporting UNIX fork like instructions etc. The authors provide detailed discussion on what are the consequences of these issues and how they can be resolved.

Drawbacks
As mentioned in the paper, virtual contiguity is a major problem in a single address space operating system. Programs are not free to select addresses for their segments, segments cannot grow and segments allocated at different times will not be contiguous in the address space. As a consequence, use of data structures assuming contiguity in memory is limited.
Absolute addressing is not possible in a single address space operating system. Secondly, since all the addresses are relative, each program has to maintain its own virtual base address. This is not required in case of a multiple address system.

Relevance

Even though the paper presents a novel way to share data among processes efficiently using single global address space, the idea is not being used in popular operating systems like UNIX and Windows. May be in the future, if 64-bit processors became common, people might use the concept proposed in Opal and develop operating systems with single global address space.

Overview
As machine hardware addressing capability increased to the point of 64bits using a single address space for all running programs becomes more feasible and as shown in this paper can provide for performance enhancement without sacrificing security. This paper explores the strengths and weaknesses of using a single address space as apposed to the more traditional approach of running each process in its own virtual space.

Problems Addressed
The primary problems addressed in this work are that of communication and sharing between processes. The argument is made that at the time separate virtual address spaces were employed hardware could only support a fairly limited address space and thus such a virtual mechanism was needed. However with advances in hardware the address space is no longer limited in the same nature and a single space that still provides protection could offer superior performance.

Contributions
Once a system is only concerned about a single large virtual address space that all processes run within such issues with virtual tag aliasing in the cache disappear. All programs simply exist as procedures in the same address space and are allowed to access each other only if they are within the same protection domain. A key idea of the paper is that addressing and protection are separated which allows for multiple protection domains to exist within a single address space. Sharing relationships do not need to be setup at the time a process is initiated, segments in memory can simply be added or removed from a protection domain at any time making the sharing organization very flexible. The system can also accommodate different languages both type safe and type unsafe. Finally the use of a mediator that controls how tools share data and interact with each other seems like a nice idea in that people developing the tools don't have to worry as much about the sharing mechanism and allowing possibly untrusted tools access to their own data.

Flaws
Since multiple instances of a procedure may have some private data associated with them that is unique to the instance this data must be replicated in memory. However in a single address space data for the different instances will exist at different addresses necessitating the need for relative addressing and maintaining a base pointer for each instance. It seems as this could cause some confusion in addressing and increase the workload to keep track of all the pointers. Also not being very familiar with the Mach kernel some of the discussion about the prototype system that was built on top of Mach was hard to follow.

Relevance
I think the authors make a good point about modern hardware being able to support a very large address space making the idea of using a single space more relevant today. It, however, goes against the traditional thinking and the way operating systems have been structured in the past and thus may be hard to implement commercially.

Summary
Chase et al. designed an operating system with capabilities and a single address space on top of the Mach 3.0 microkernel.

Problem
Separate sharing and protection mechanisms to enable more efficient sharing for high performance applications.

Contributions
The authors present a good summary of the advantages and disadvantages of the single and multiple address space approaches. They also detail a good argument of the benefits of direct dynamic linking, along with pointing out that much of copying done in the fork procedure is unneeded.
Their idea of copy-on-write is an interesting concept that could be incorporated into other systems. The paper contains a very comprehensive report on all of the mechanisms they provided (ex. Protection domains, protection, sharing, …). I am not certain it is a novel contribution, but implementing their prototype alongside other environments was a good idea. Being able to run Opal for your CAD package and still being able to use UNIX for sshd would make this much easier to implement in practice.

Flaws
I did find it paradoxical that in the same paragraph where it is speculated that a 64-bit address space will last for 500 years the authors also point out that the average address space needed is doubling every year.
The evaluation of the system could have been better done with a different approach. An analysis at more fundamental levels would have been more convincing. At the application level it is hard to tell if these gains will generalize to other applications or if the gains are specific to this program. For instance they mention gains in the Boeing system due to storing information as direct pointers instead of using a database. They are making a tradeoff here in favor of performance. Direct pointers do allow for the same functionality as a full-fledged database. Such as transactions, concurrency, crash recovery. Even if the code were engineered so the direct pointers could supply these functions a gain still would be expected, due to the fact that the database (composed of code using direct pointers) was custom built for the application. The Boeing analysis did not convince Opel improved performance.

Relevance
At least for me, this paper showed me there are simpler ways of sharing information outside of the Unix world. A number of interesting ideas are presented, but they don’t seem to have made it into commercial systems (to the best of my knowledge) yet.

Paper Review: Sharing and Protection in a Single-Address-Space Operating System [Chase, et. al.]

Summary:

This paper presents the memory sharing and protection scheme used in
Opal, a Single-Address-Space Operating system for 64-bit architectures.
features.

Problem:

The problem addressed is to improve reliability and/or performance of
complex applications, especially those that use large data structures,
by changing the operating system and software organization.

Contributions:

Opal acheived performance and/or protection gains by utilizing the
wide-address capability of 64-bit architectures, along with improvements
(proposed by prior works) in operating systems and languages, to build a
fairly complete system.

Opal achieved full separation of addressing from protection. This was in
the form of a single-address-space with threads running in a "protection
domain" rather than processes with virtual address space.

The most compelling advantage to this design is the performance gain by
doing communication via shared-memory rather than common mechanisms that
require the serialization of (often pointer laden) data objects into
intermediate formats. Pervasive sharing through memory is ideal,
especially for large software environments and some database
applications.

Flaws:

While it is believable that a large performance gain can be realized
(perhaps on the order of a magnitude), the authors did not use their
prototype to quantify the performance gain acheived by the
single-address-space operating system by replacing non-shared-memory
inter-process communication techniques with direct memory sharing.

Since it seems the most compelling feature is performance gains through
placing just data objects shared-memory, perhaps a hybrid system with
traditional process that can also reference a nearly 64-bit global
address block would be more easily migrated to (such as Hemlock?)
Still, some segment-specific protection scheme such as proposed here
would be necesary for protection of global data objects.

Although software for tradition multiple-virtual-address architectures
is source-portable to single-address-architectures, the converse is not
true.

Relevance:

It may be too early to tell but, thus far, 64-bit architectures have
primarily been used to host ports of existing, previously only 32-bit,
operating systems, just with improved instruction execution performance.