From: Chuck Reeves (creeves_at_windows.microsoft.com)
Date: Wed Jan 14 2004 - 14:21:21 PST
Sharing and Protection in a Single-Address-Space Operating System is a
paper written around 1994 by a number of researchers associated with the
University of Washington. Leveraging a prototype called Opal (built on
the Mach 3.0 microkernel) the paper discusses how the principles of
memory sharing and protection can benefit from the adoption of a 64-bit
single-address-space operating system.
Similar to the spheres of protection disccussed in Dennis and Van Horn,
the authors chose to seperate addressing from protection. This is
necessary to enable the simplification sought from establishing a single
address space for all referenced information across the system (the
authors make the interesting case that this could be across all of space
and time on a single machine). The paper contrasts some of the methods
for sharing information between programs in systems using
multiple-private vs single-shared addressing schemes. I think they make
a good case, that for heavily normalized data containing a lot of
pointers that the single-shared model has some great advantages.
Opal provides a coarse-grained protection scheme based on segments and
capabilities. Executing threads gain access to a segment by virtue of
their association with a protection domain. The segment capabilities
associated with the protection domain can be amended using Attach and
Detach.
Conveniently, segments can also be transparently attached on address
faults. This is done, by publishing a segment capability with an ACL.
Execution of code that bridges protection domains does require some
level of involvement by the system. This facility is enabled through the
publication of discrete entry points called portals.
I loved the idea of information being persistent (or pinned) in memory.
The idea of being able to retain data in it's useful form across reboots
and application starts sounds like a dramatic simplification from the
way we do this today.
The heavily normalized data model and the large user base of the Boeing
CAD system seemed like a logical choice to test the benefits of this
system. The publish and subscribe system (named Mediator) used to notify
tools and applications of data changes was fitting for this specific
case, it would be interesting to see how effective this solution would
be under other circumstances.
The shear capacity implied by a single, shared 64-bit address space
implies some interesting ideas about what the installation profile of a
computer might look like. It would seem logical that the persistent
state of the machine would be dramatically different from how it is
today. Instead of having applications installed (streamed) onto disk. It
would seem that they could simply exist "resident' in memory perhaps
paged out, but ready to be invoked with no requirement for all the
loading and dynamic loading we see today. While there would certainly be
disk activity in interacting with dormant applications, this model
would certainly have to cut down on program execution at startup time,
perhaps similar to a return from hibernation.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 14:22:18 PST