SASOS

Single Address Space Operating System

90年代の初めから中ごろにかけてOS研究の分野では Opal をはじめとした SASOS が大流行だった．また，Exokernel や SPIN はカーネルレベルではアドレス空間モデルを規定していないので，単一アドレス空間モデルを採用することも可能である．Lavenderのレジデントアドレス空間や，Tenderのヘテロ仮想記憶では，部分的に単一アドレス空間モデルを採用している．

• なんで流行したんだろう？90年代は連続メディアに代表されるマルチメディアを 扱うシステムがはやったけど... 単一アドレス化そのものは，Multicsや，system/38, apollo domainとかでも あったわけだし．64ビットプロセッサを視界に入れて，スレッド間の通信の軽減や， データアクセス機構の一般化みたいなのが潮流だったのかなあ．う〜ん... --- Hayakawa

• やっぱり64bitプロセッサの登場が大きかったと思います． そして64bitの(広大な)アドレス空間をどう使うかということで， ワンレベルストアシステムが見直された感じじゃないですか? -りょうせい

Mach など多重アドレス空間モデルのカーネルでは，タスク間での通信やデータ共有の際にコンテキストスイッチのオーバヘッドがかかる．そこで，タスク間でアドレス空間を共有し，高速化しようとしたのが SASOS である．ただし，SASOS は本質的にセキュリティが問題になるので，保護ドメインやケイパビリティを利用した保護機構が必要になる(拡張性と保護のトレードオフ)． . ＃また，実際にはメッセージパッシングのオーバヘッドはそれほどでもないという論文もあったような気が... 調べてみよ．実際に使われているメッセージの大半はサイズが小さいから，オーバヘッドは小さいという趣旨だった気がする．

SASOSとしては，その他にも Angel，Nemesis，Cubix，Mungi，AS/400，Sombreroなどが存在する．

---

SASOS の場合，多重アドレス空間とは異なり，タスクごとにアドレス空間が独立していないので，メモリにマップされたデータに対する保護の問題がある．

例えば，データ foo が存在し，foo へのポインタ pfoo を用いて，次のように不正オフセットでアクセスすると，foo 以外のデータを破壊してしまう． {{{ *(pfoo + 0xfffff) = 777 }}}

(SASOSの場合)これをページングだけをサポートする MMU で防ぐことは不可能であり，何らかの防止策をカーネルが提供する必要がある． 一般的な 保護モデル としてはケーパビリティ，ACLが挙げられる． . 通常，ファイルシステムのread/writeやメッセージパッシングのsend/receiveなどのインタフェースを介して，資源にアクセスする．この場合，インタフェースの部分でその資源へのアクセスが許可できるかチェックすることができる．

また，アドレス空間を共有することによってプログラムのリンク機構も異なってくる．

• SASOSとリンク機構

---

SASOSとMacOS(MacOSX以前のバージョン)やMS-DOSとの違いは何か．

すべてのプロセスがアドレス空間を共有する点は両者共に同じであるが，(メモリ保護の有無は置いといて)データに対して一意な仮想アドレス空間が割当てられる点が大きく異なる． . つまり，SASOSではデータが生成されアドレス空間に割当てられると，そのデータが消去されるまで(たとえOSがリブートしても)そのアドレス空間に存在することになる．したがって，ファイルシステムは存在せず(既存のOSとの互換性のためのインタフェースを提供することはありえるが)，ディスク操作はページャによって処理される． MacOSなどの場合は，ファイルをopenするたびに異なるアドレス空間にマッピングされる．って，MacOSにメモリマップトファイルがあるのかは知らないけど．Unixのmmapはこんな感じだから，これをワンレベルストアと言うのは，やはり私的には気持ち悪いのだ．

---

改めて考えてみると，JavaやSmalltalk，Lispなどの実行環境は単一アドレス空間OSであると言える．Javaは，言語レベルでの保護を提供しているが，それだけでは不十分であるため，実行環境としていろいろな機構が研究されている．研究の多くは，リソース管理，保護関連である．また，名前を識別子とし，名前を介してのみ，変数，または関数にアクセスできる場合は，型安全性が重要になる．