From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Jan 14 2004 - 03:54:11 PST
This paper describes the Opal system, which is a single-address-space
operating system that takes advantage of the address space provided by
64-bit architectures. The big advantage of a single-address-space is the
separation of addressing from protection, which allows procedures in
separate protection domains (typically different processes in conventional
operating systems) to share data by reference. While this concept of shared
memory was not new, the single-address-space approach allows sharing without
a priori coordination on behalf of all involved processes in setting up a
special shared memory space. With a 64-bit addressing scheme, Opal is also
able to use globally-unique-across-time, virtual memory addresses and even
persist segments.
The authors justify the single-address-space approach by explaining that
in order for two procedures to share data they must make at least one of
the following compromises: 1) collocate in the same protection domain,
2) copy data by value and marshal the data from one process to another
using messages, files, or pipes, or 3) in some operating systems, set up
a special shared memory space in advance.
While Opal handles storage allocation, protection, reclamation, and even
persistence, the paper emphasizes the coarse-grained (also could be called
segment-grained) approach to memory management, leaving fine-grained control
to language compilers and runtimes.
Access to resources is based on capabilities (adapted from the Dennis/Van
Horn paper and the Wulf et al. HYDRA paper). All segments are potentially
attachable to a protection domain given the proper capability. I
particularly found it interesting the way a runtime fault handler can request
a published capability upon an address fault, receive it and attach the
segment before returning from the address exception. In order to transfer
control from one domain to another, the system has the concept of entry
points called "portals", which is identified by a 64-bit value by a thread
that requests transfer of control. The Opal version of a capability is
this portal id + the object address + "randomized check field that verifies
authority to operate on the object" (how this works wasn't very clear to me).
Resource Groups and Reference Objects appear to be used to make memory
management work through reference counting, without letting a thread release
more resources than it actually acquired (since this would affect the same
reference count used by other processes).
I didn't find the implementation section especially valuable, partly due to
my ignorance of Mach, but also because I felt like the paper was already
giving me plenty to think about without going into the implementation
issues that came up with Mach and the side by side Unix issues. However,
I did find the "Applications and Performance" section interesting. The
discussion of how to get separate tools to share info, the benefits of
using a virtual memory location instead of having to map to some other
key in database, plus the mediator concepts were all very compelling.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 03:54:14 PST