From: Richard Jackson (richja_at_expedia.com)
Date: Wed Jan 14 2004 - 17:41:21 PST
This 1994 by Chase, et al is a great documentation of a
single-address-space operating system called Hydra. The paper is
extensive, going into great detail about the design, architecture,
implementation issues, applications, performance, weaknesses, etc.
There aren't many areas left unaddressed, and the paper will be
challenging to most readers.
The key idea of the paper is the concept of a pure, single-address-space
operating system. This operating system is designed with 64-bit
wide-address hardware in mind. The authors state that the current
64-bit hardware enables systems such as Opal to now be possible.
Previous hardware limitations prevented pure single-address-space
operating systems from being realized.
The first section describes a justification of the system. It goes into
detail about why current virtual-address-space systems are insufficient
for current needs. The main argument is that applications can not
easily share data, because their virtual-address spaces are
context-dependent. That is, their memory pointers will mean nothing to
another process, unless some translation mechanism is employed. The
authors consider all of this to be too much overhead, and thus propose a
single-address-space operating system as the solution.
The next section goes into detail about the various Opal abstractions.
These include things such as 'segments'(basic unit of storage),
'threads'(units of execution), 'protection domain'(execution context for
a thread), etc. Access control is also described. This system is
capability-based, similar to the methods we've seen in previous papers.
"password capabilities" were mentioned a few times in this paper, but I
never got a good sense of what this means. Finally, this section
discussed 'portals', which are a means for inter-process-communication,
which allow runtime specification of sharing between threads in
different protection domains.
The next section described how an implementation of Opal was built on
top of the Mach microkernel, alongside an existing UNIX implementation.
Various details of the implementation were provided, and it gave a
convincing argument that such a system could actually be built.
However, some concessions were made because of the Mach kernel
abstraction, so I question if Opal would work even better if built on
top of a native kernel. The paper later suggests the same.
Next, the authors discuss a sort of beta-test for Opal, using CAD
systems being developed at Boeing. This system successfully
demonstrated the use of Opal in a somewhat-real environment. The
authors also gave performance data, showing that Opal performed
favorably when compared to non-single-address-space systems. One problem
I had with this section was that the authors made a quite qualitative
statement at the very end of 5.4: "we expect applications to ultimately
perform better in our environment due to the ease of direct memory
sharing and the simplified use of persistent storage." I don't think
they gave enough evidence to support this assertion.
The paper concluded with a discussion of weaknesses of the design, and a
list of comparisons to other related systems. For the former, my
biggest concern was that of recycling. The authors say that it isn't
very important, but I think it should be given more consideration.
Regarding other related systems, the Opal system seemed most like the
Monads system. The other mentioned systems were all similar in some
ways, but always had a key difference. I think that Opal is the purest
single-address-space operating system among those mentioned here, and
surely this is what the authors intended.
Overall, I think this paper presented a very compelling argument for
single-address-space operating systems. Based on current hardware
capabilities, it seems like such designs should be pursued. The main
difficulty in building such systems is that current applications would
need to be modified to work in the different scheme. One of the other
mentioned systems, Hemlock, addresses this by using a hybrid scheme of
both global and private address spaces. The goal of Hemlock is backward
compatibility, which is a key design consideration in modern systems.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 17:41:32 PST