Spring（オペレーティングシステム）

Springカーネルは、仮想メモリシステムとコアの2つの部分に分かれていました。コアはMachカーネルの一部に相当しますが、各OSのカーネルは十分に類似しているため、同じ機能を果たすものとみなすことができます。

Springカーネルには、ユーザー側アプリケーションをサポートするために必要な最も基本的な機能と状態のみが含まれています。これには主に、実行中のプログラム（ドメイン）とそのスレッドのリスト、およびそれらの間の通信リンク（ドア）を維持するための状態が含まれます。

Springカーネルはマルチスレッドではありません。通常、これはリアルタイム環境での使用を妨げる要因となりますが、必ずしもそうとは限りません。通常、カーネルは、ディスクI/Oなどの長時間実行されるタスクがシステムを占有して後続の呼び出しが時間内に処理されなくなることを防ぐために、スレッド化する必要があります。Springでは、カーネルはリクエストの大部分をほぼ即座にサーバーに渡すため、このモデルでは、理論的にはサーバーのみがスレッド化される必要があります。

MachとSpringの大きな違いの一つは、IPCシステムでした。Machでは、システムはプログラム間の単方向非同期パイプ（ポート）のセットとして構成されており、これはUnixパイプから派生した概念です。しかし、プログラミングにおいて最も一般的な通信方法はプロシージャ呼び出し、つまり呼び出し/戻りですが、Machはこれを直接サポートしていませんでした。呼び出し/戻りセマンティクスは、基盤となるポートメカニズムに基づいた上位ライブラリの追加コードによってのみサポート可能であり、そのため複雑さが増していました。

Springは、基本通信システムにおいて呼び出し/戻りセマンティクスを直接サポートしました。これにより、Machのポートという用語がSpringのドアという用語に変更されました。ドアはカーネルのみが認識し、プログラムにはそのプログラム固有の識別子を持つドアへの「ハンドル」が渡されました。このシステムは、最初のメッセージに関してはポートと同様に機能しました。ドアに送信されたメッセージは、ターゲットアプリケーションを見つけてドアハンドルを変換するためにカーネルによって検査されましたが、その後、カーネルは呼び出し元から少量の情報を記録し、データを迅速に返せるようにしました。これにより、戻り処理が約40%高速化されました。

さらに、Mach モデルは非同期でした。つまり、サーバーがデータを持っている場合にのみ呼び出しが返されました。これは、サーバーがビジー状態のときに他のプログラムを実行できるようにする、オリジナルの Unix パイプ モデルに倣ったものでした。しかし、呼び出し/戻りシステムでは、タスク スケジューラを実行して次に処理するプログラムを選択する必要があるため、深刻な欠点がありました。うまくいけば、これが呼び出しがデータを要求しているサーバーであるはずでしたが、保証はされていませんでした。Spring では、IPC は同期です。スケジューラを実行せずに制御がすぐにサーバーに渡されるため、サーバーがすぐに返せる一般的なケースでは、往復時間が短縮されます。

Machでは、メモリ管理ユニット（MMU）によってサポートされる仮想メモリシステムが、メモリ内の同じデータを2つのプログラムにマッピングするだけで、軽量なデータコピーソリューションを提供することが期待されていました。しかし実際には、多くのMMUにはこのマッピングを遅くしたり、場合によっては不可能にしたりする設計上の特徴があったため、このソリューションは全く効率的ではありませんでした。

MachのIPCに対する画一的なソリューションとは異なり、Springはプログラム間でデータを物理的に渡すためにさまざまな方法を採用していました。そのうちの1つであるバルクパスは、基本的にMachのポートとメッセージと同じでしたが、実際にはバルクパスは最も使用頻度の低いメッセージタイプでした。より小さなメッセージの場合、Springはバニラパスを提供していました。これはデータをある領域から別の領域に直接コピーするもので、5KB未満のデータであれば、実際の環境ではメモリマッピングよりも高速であることが証明されました。

高速パスにより、少なくともSPARCベースのプラットフォームで実行する場合、非常に高速な呼び出しが可能になりました。高速パスは、 Mach システムを悩ませていたコンテキスト切り替えのオーバーヘッドの多くを回避するために、独自の「ハーフトラップ」を使用しました。カーネルへのトラップの場合の通常の手順であるプロセッサの状態全体を保存する代わりに、Spring は SPARC アーキテクチャの特定の実装の詳細によって定義された上位 16 個の SPARC レジスタのみを保存しました。レジスタスタックのその他の部分は、SPARC のWIM命令を使用して受信側から見えなくなり、ある程度のセキュリティが提供されました。高速パスは、単一アプリケーション内の古典的なプロシージャ呼び出しに非常によく似ており、 SPARC のレジスタウィンドウを使用し、コンテキストをあるプログラムから別のプログラムに移動するために MMU の処理を​​追加します。

高速パスは、変換する必要のない単純な値（例えば、ドア参照など）を渡す呼び出しでのみ利用可能で、合計で最大 16 個の値まででした。これはかなり制限されているように見えますが、実際には Spring の呼び出しの大部分（一般的に呼び出しの 80% 以上、戻り値の約 60%）で高速パスが使用されています。戻り値は、ディスク ブロックなどの大きなデータ ブロックで応答することが多いため、戻り値で他の IPC システムがより頻繁に使用される理由が説明できます。

32 ビットSPARC V8 システムでは、高速パスを使用した完全な往復呼び出しは 100 命令強で完了し、一般的な Mach 呼び出しよりも何倍も高速でした。高速パスが他のマシンで実装できるかどうかは不明なため、Spring の全体的なパフォーマンス向上を、通常IA- 32 システムで測定された Mach と比較するのは困難です。具体的には、既存のBSD Unix システム用の 486DX-50 では完全なシステムコールに 20 μs 未満かかり、Mach では 114 μs かかりました。これにより、パフォーマンスが 50% 以上低下し、ほとんどの Mach プロジェクトが失敗に終わりました。対照的に、高速パスを使用した Spring は、 SPARCstation 2でIPC 時間がわずか 11 μsであることを誇っていました。  

Springにおけるもう1つの重要な改善点は、カーネルの一部でもある仮想メモリ（VM）システムの実装でした。仮想メモリは、マシン内の物理ランダムアクセスメモリ（RAM）、MMU、およびディスクシステムを連携させ、システム上のすべてのプログラムが、マシンとオペレーティングシステムがサポートできる最大容量に等しい独自のRAMブロックを持っているかのような錯覚を作り出すシステムです。1980年代と1990年代に使用されていたコンピュータとオペレーティングシステムで最も普及していたメモリアドレッシングモデルは32ビットで、理論上の最大4GiBのメモリへのアクセスが可能でしたが、2000年代初頭までは、それほどの物理RAMを搭載していたのは比較的高価なコンピュータだけでした。VMシステムは、ハードディスクをバックアップストアとして使用することで、より多くのメモリがあるかのような錯覚を作り出します。バックアップストアとは、RAMの非アクティブな部分をオフロードするために使用される、はるかに低速なメモリ領域です。 

従来のUnixシステムでは、VMはカーネルの一部であり、VMが連携するディスクハンドラとメモリハンドラも同様です。Machでは、VMシステムをどこに配置するかという決定はそれほど明確ではありません。カーネルはRAMとMMUを制御しますが、ディスクハンドラは外部クライアントプログラムの一部です。この問題を解決するために、Mach 3では新しい2層VMシステムが導入されました。実際のVMシステムの制御はカーネルで行われ、外部クライアント空間のページャーにディスクシステムとのやり取りを要求してメモリを物理的にコピーします。残念ながら、これは深刻なパフォーマンスの問題であることが判明しました。VMシステムのさまざまな層が互いに呼び出し合うため、カーネルへの出入りが何度も必要となり（それに伴いコンテキストスイッチも発生します）。

Springチームは、Machモデルの問題点を検証し、修正できるという利点を持っていた。その結果、プログラム内のアドレス空間がより明確に分離されたシステムが実現した。このシステムは、VMによって様々なメモリオブジェクトにマッピングされ、さらにページャーによってバッキングストア処理が管理される。プログラムがデータを要求すると、その要求はカーネル内のVMシステムに渡され、VMシステムは適切なページャーを見つけて、適切なメモリオブジェクトの作成と設定を依頼する。その見返りとして、ページャーにはVMからキャッシュマネージャが渡され、このキャッシュマネージャは、そのメモリオブジェクトのローカルキャッシュのクリーン/ダーティ状態を追跡する役割を担う。実装の詳細によってこのモデルはかなり複雑になったが、そのほとんどは隠蔽されていた。最終的に、基本的なシステムには、メモリを管理するページャーと、キャッシュを管理するアドレス空間があった。両者は明確に定義されたインターフェースを持ち、コマンドをやり取りしてデータを同期させることができた。

この役割分担によって、非常に大きなパフォーマンス向上が実現しました。プログラムはメモリオブジェクトを共有できるため、Springのようなマイクロカーネルシステムはメモリのコピーを基本としており、Springではこのようにメモリを共有するプログラムがVMシステム内でもメモリを共有できるようにしました。そのため、Machではネットワークファイルサーバーがプログラムにデータを渡す場合、両方のプログラムがVMシステム内のメモリを消費することになりますが、Springでは、そのメモリオブジェクトを実装するページャーが同じメモリへの別のハンドルを返すだけなので、両者は自然に同じメモリオブジェクトを共有します。VM内部でのみ、これらは異なるオブジェクトとみなされ、別々のキャッシュマネージャによって処理されます。したがって、データはRAMに一度だけキャッシュされます。理論的には、これにより実際のRAM使用率が大幅に向上する可能性があります。

さらに、明確に定義されたAPIを備えた外部ページャーを使用することで、必要に応じてシステムを明確に分離することができました。Springでは、プログラム自身がどのページャーがニーズに最適かを指定できるため、既知のワークロードに対してプライベートVMシステムを容易に実装できます。ファイルサーバー、Webサーバー、データベース管理システムなどのアプリケーションでは、カスタムVMとファイルシステムによってパフォーマンスが劇的に向上することがよくあります。

ほとんどのオペレーティングシステムには、さまざまなネーミングサービスが含まれています。最も基本的な例はファイルシステムで、ファイルは内部的に「ハンドル」と呼ばれる小さな数値で参照され、ユーザーが操作するファイル名は別のディレクトリによって与えられます。このような名前と識別子の二分法は、一般的なUnixシステムの他の多くの部分にも見られます。プリンタはファイルで名前が付けられetc/printcap、環境変数には小さな数値や文字列が、ネットワークの場所はDNSで指定されます。これらのシステムはそれぞれ独自の名前とカスタムAPIを提供しており、異なるオブジェクトは概念的にも全く異なるものに見えるようになっています。

他のシステムも既存のUnixシステムに命名システムを追加しようと試みたが、それらは概して既存の機能の上に「カバー」を施したもので、様々なサービスからすべての名前を集めて1つのコレクションとして表示するだけだった。基盤となるシステム構成に関する知識に依存していたため、柔軟性に欠け、新しいサービスの追加が容易ではなかった。これらのシステムはほとんど利用されなかったようだ。

完全に新しいオペレーティングシステムでなければ、普遍的なサービスを提供することは望めなかった。例えば、Plan 9はファイルシステムを普遍的なネーミングサービスとして利用し、プリンタからウィンドウまで、あらゆるものにファイルシステムを介して名前でアクセスできるようにした。これは、長年にわたって機能が追加されるにつれて徐々に失われていった、オリジナルのUnixの概念を拡張したものである。

Machにはポートの名前付けサービスが一切ありませんでした。これは深刻な問題でした。なぜなら、プログラムはカーネルにポートの提供を要求するために、どのサーバーを呼び出す必要があるかを事前に知っておく必要があったからです。つまり、機能の置き換えが本来よりもはるかに困難でした。例えば、新しいプリンタサーバーは古いサーバーと同じポートを使用する必要があり、開発のために2つのサーバーを並行して実行することはできませんでした。ポートを名前で参照できれば、サーバーは異なるポートを使用し、同じ名前を使うだけで済みます。この機能は、ネームサーバーによって提供され、Springでは非常に重要視されました。

Springのアプローチは、基本的にPlan 9システムを逆転させたものでした。Springでは、ファイルシステムは単一の統一された名前サービスを使用するサーバーの一例として位置づけられていました。同じサービスを使用して、ディスク上のファイル、環境変数、ハードウェアデバイス、プログラム、さらにはプログラム内のオブジェクトに名前systemを付けることができました。システムは階層構造になっており、起動時に起動するサーバーによって直接サポートされるのは名前空間のみでした。他のサーバーは、認識している名前をシステムに「バインド」しました。たとえば、プリンタサーバーはプリンタのリストを生成し、ファイルシステムは接続されたディスクのディレクトリをバインドしました。このようにして、システム上のすべてのオブジェクトのマッピングが、場合によっては実行時に構築され、Plan 9と非常によく似たファイルライクな方法でアクセスできました。これらすべてに単一のAPIを使用してアクセスできましたが、システムは、特にUnixエミュレーションサーバーにおいて、従来のサービスのように見せるためのさまざまなスタブライブラリも提供していました。

名前サービスは、セキュリティと権限管理の中心でもありました。Spring における実際のアクセス権限である「ドア」は名前サービスによって付与されるため、サーバーにはアクセス制御リストに基づく完全な権限チェックシステムが含まれていました。そのため、Spring ではファイルシステムに対する権限付与に加えて、あらゆるオブジェクトを同じ権限セットとユーザーインターフェイスを使用して制御することができました。例えば、 Windows NTには約 12 種類の権限管理システム (ファイルシステム、DCOM、SQL アクセス、IIS など) があり、それぞれを個別に設定する必要があるのとは対照的です。パフォーマンスを向上させるため、このシステムには信頼の概念が組み込まれており、名前サーバーが他のサーバーからの要求を有効とみなすことができました。例えば、ユーザーがファイルサーバーにファイルへのアクセスを要求すると、システム名前サーバーは要求をファイルシステムに転送し、ファイルシステムはすぐに要求に応じます。ただし、ユーザーが不明なため、アクセスされるファイルに対してアクセス制御リストがチェックされます。

関連する名前のグループはコンテキストと呼ばれていました。コンテキストも名前であり、ファイルシステムのディレクトリの概念に似ています。ユーザーは、一見無関係なオブジェクトから独自のコンテキストを作成することができました。完全に別々のドライバ（サーバー）を使用するプリンタを単一のリストにまとめたり、ファイルが異なる場所（または異なるユーザー）で異なる名前を持つようにしたり、検索目的ですべての個人ファイルを含む単一のドメインを構築したりすることができました。このようにして、Springはファイルディレクトリを「統合」することを可能にしました。これは、従来のUnixenにはなかった便利な機能です。

Springには組み込みのオブジェクト永続化システムは含まれていませんでしたが、ネームサービスは永続的であり、このような方法でオブジェクトを検索するために使用できました。ブート時に起動される一連のサーバーは、ある程度、同じサーバーに名前をコピーすることで、ブート後も存続する永続的な名前空間を提供していました。理論的には、このシステムでは、たとえば誰かが要求するまでネットワークサーバーを起動しない「遅延起動」システムをネームサーバーに提供できますが、この機能は含まれていなかったようです。実際には、名前空間を分離することで、ドアの名前付けを実際に実装するサービスにこの機能を分離することができ、実装がかなり容易になります。

Spring VMでは、どのプログラムでも使用するページャーを定義できました。さらに、Springシステムは単一の共通命名システムに基づいていました。これら2つの概念が組み合わさって、Springファイルシステムが誕生しました。

Springファイルシステムの動作の鍵は、VMシステムとの緊密な統合でした。VMシステムがファイルシステムからのデータのローカルキャッシュを管理することが「既知」であったため、ファイルシステムはコマンド構造のみに縮小され、独自のページャーとして機能しました。つまり、ファイルシステムは必要に応じてメモリオブジェクトからデータをロードおよび保存する役割を担いましたが、データのキャッシュはVMによって処理されました。これは、Springでは、システム内のプログラム間でファイルがどのように共有されていても、ファイルはRAM上の1箇所にのみ存在することを意味します。

Springは2種類のファイルシステムを使用していました。1つは一般的なUnixシステムに似たローカルファイルシステム、もう1つはネットワークデバイス用のキャッシュファイルシステムです。キャッシュシステムは、SpringのVM/ページャー分割の有用性を示しています。通常VMが使用するのと同じ物理メモリを使用することで、CFSはすべての読み取り要求をローカルキャッシュにショートサーキットし、30秒ごとにソースファイルシステムに遅延書き込みを行いました。これは、一般的なUnixディレクトリがネットワーク経由でロードされる場合（ワークステーションのラボの通常の構成）に特に顕著でした。ほとんどのUnixシステムは、同じパフォーマンス上の理由で同様のキャッシュメカニズムを使用していますが、キャッシュとそれを使用するプログラムでそれぞれ1回ずつ、合計2回RAMを使用することになります。CFSはリモートシステムからの名前もキャッシュしていたため、最初のディレクトリ走査とオープン要求がはるかに高速になりました。

Springのファイルシステムは、名前サービスコンテキストプロバイダとしても機能し、ディスク上の構造からディレクトリを名前サービス内の新しいコンテキストに遅延的にマッピングします。これらのコンテキストには、ユニバーサルネーミングAPIを使用してアクセスすることも、あるいは従来のUnixファイルシステムとして提供するUnixエミュレーションライブラリを介してアクセスすることもできます。

Springにおける「ファイルシステム」という用語の使い方はやや紛らわしいので注意が必要です。通常、この用語はディスク上にファイルを物理的に保存する特定の方法を指します。

Springは、Sunの事業基盤である既存のUnixアプリケーションもサポートする必要がありました。そのため、Springには2つの重要な拡張機能が同梱されました。1つは完全なUnixを模倣するUnixプロセスサーバー、もう1つは標準libcライブラリを書き直したlibueで、Unixカーネルの要求をさまざまなサーバーにリダイレクトします。例えば、ファイルサービスやネットワークサービスを必要とするUnixアプリケーションは、関連付けられたSpringサーバーにリダイレクトされ、現在実行中のプログラムの一覧を取得したいアプリケーションは、Unixプロセスサーバーにリダイレクトされます。プロセスサーバーはシグナルの処理も担当していましたが、シグナルはSpringには対応する概念がなく、また、シグナルは基本的に柔軟性に欠ける単一目的のIPCメカニズムであるため、後方互換性以外には実際には必要ありませんでした。

Spring上でUnixアプリケーションを実行するには、 libueへの再リンクが必要でした。システムには、基本的なUnixユーティリティの大部分とX11サーバーが再リンクされた状態で同梱されていました。しかし、この互換性確保の方法は、目に見えないものでも、動作が保証されているものでもありませんでした。Springのドキュメントには、「多くの」アプリケーションは（再リンク以外は）変更なしで動作すると記載されていますが、そうでない場合に開発者がどのような問題に直面する可能性があるかについては触れられていません。

Springそのものとは直接関係ありませんが、このプロジェクトに携わっていたSunのエンジニアたちは、様々な種類の呼び出しをサポートするための既存のメカニズムが十分に定義されていないことに気づきました。よりリッチなインターフェースを提供するために、彼らはサブコントラクトという概念を開発しました。