From: Brian Milnes (brianmilnes_at_qwest.net)
Date: Wed Jan 14 2004 - 15:28:25 PST
Sharing and Protection in a Single-Address Operating System - Chase et al
The authors propose a radical change to modern operating system called
Opal. Opal allows sharing of data by decoupling addressing and protection.
The concept of a process in a private address space is replaced with threads
running in protected segments of a single global address space. This address
space is protected using capabilities and capabilities can be published and
looked up in a service guarded by ACLs. Protected calls similar to those of
Multics are implemented. A garbage collection by reference counting is
needed for segments and to replace the easy cleanup at the end of process
life, resource groups are added.
This design does not limit modularity, allows segments to be easily shared
with varying levels of trust, allows segments to be stored persistently on
disk and could share the address space in a cluster. Other approaches have
paid a very high cost for protection like this unless they have relied upon
a single type safe programming language for protection.
They implemented this design under the Mach 3.0 microkernel and show
performance roughly equivalent to the native Mach operations. As Mach 3.0 is
quite expensive, due to the high cost of its messaging and server
architecture, what they've really shown is that their operations are quite
cheap as they have mostly been implemented using the Mach primitives.
This is a radical departure from the normal style of Unix programming. A
process like a web server is constructed with a single mother process that
forks to share initial data and to allow multiple children to read from the
same socket. My attempts to get these children to synchronize on shared data
and to communicate has required a large amount of work and a great drop in
performance. My experience building systems under Unix makes the Opal model
very tempting.
Some of the problems with shared single address space are that programs can'
t grow their segments, in practice the address space must be recycled, Unix
fork can not be implemented, data copies must have pointers remapped and
copy on write requires read only aliasing. Another weakness with the paper
is that the restructuring of Boeing's CAD environment is a dissatisfying
example. The restructuring is clear but the benefits of this aren't seen in
any great way. It is also a shame the authors chose to skip the flushing of
persistent segments to disk and crash recovery. I have written data in
shared memory segments and this caused serious IO loads. You must somehow
schedule with the kernel how aggressively it should write versus how much
work or loss that you can tolerate during recovery.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 15:28:45 PST