マイクロカーネル
実際に実装されたMachでは、当初の予想通りコード量の削減には成功した。抽象度が高く、見通しの良いマイクロカーネルはトレンドとしては妥当であり、この時は将来有望な物と見なされている。しかし、その間にコンピュータの性能がネットワーク性能に比べて格段に向上し、マイクロカーネルの性能問題は開発の容易さという利点を考慮しても無視できなくなった。既存システムを性能向上させる様々な試みがなされたが、オーバーヘッドが常に問題となり、性能向上のためにはユーザー空間のプログラムとなったサーバをカーネルに戻す必要があった。2000年までにMachのような大規模な試みはなされなくなったが、OPENSTEPが採用したXNUというMachカーネル改良版は Darwin や macOS で採用されている。2012年現在、Machベースの GNU Hurd も機能しており、それを採用した Arch Linux と Debian のテスト版も進行中である。
マイクロカーネルの大規模な研究は下火になったが、研究開発は続けられた。初期のマイクロカーネル設計における性能問題の多くは方針の根本的の問題ではなく、たまたまある目的のために実装されたシステムを可能な限り多くのサービスに使おうとする設計者の願望に起因していたと見られるようになった。アセンブリコードを使ったり、通常はソフトウェアでサポートすることをプロセッサのアーキテクチャ独自の機能に頼るなどのより実用的なアプローチを通して、性能が劇的に改善されたマイクロカーネルが登場するようになった。
そのような背景で1980年代に開発されたマイクロカーネルは、既存の一体型カーネルを新たなシステムへ適応させるいくつかの試みを伴っていた。従来型カーネルに含まれていたデバイスドライバ、プロトコルスタック、ファイルシステムや他の低レベルシステムを一度に新たに開発するため、膨大な作業を伴い、慎重なコード管理が必要とされた。ユーザー空間のプログラムとして実装されたサービスは通常のユーザープログラムのように動作する。そのためそれらサービスの扱いが容易になっただけでなく、残ったカーネル部分は副作用を気にせずに最適化することができる。さらに言えば、共通の中核部の上に全く新たなOSを構築することも可能になり、OS研究にも寄与した。
なお、この時古くなった計算機資源の再利用も考慮されていた。つまり、移植性が高くコンパクトなOSを使えば、旧式のシステムであってもネットワーク上に接続して資源として活用する事ができるという考え方である。
1980年代には初期の Local Area Network が登場しており、マイクロカーネルは非常に有望な技術とされていた。カーネルの機能をユーザー空間に分散させる機構を使えば、システムをネットワーク上に分散させることも可能だからである。Machなどの初期のマイクロカーネルは、性能に問題があることが判明したが、それよりも利点が大きいとみなされ、1990年代末までOS研究の中心となった。
多くの主流のプロセッサにおいて、サービスを得るのにかかるコストはモノリシックカーネルよりもマイクロカーネルの方が本質的に高い。モノリシックなシステムでは、サービスを得るのに1回のシステムコールを使用し、その際に2回の「モード切り換え」(プロセッサのリングまたはCPUモードの変更)を必要とする。マイクロカーネルを採用したシステムでは、サービスを得るにはサーバにIPCメッセージを送り、別のIPCメッセージで結果を得る必要がある。このときドライバがプロセスとして実装されていればコンテキストスイッチが必要であり、プロシージャとして実装されていれば関数呼び出しが必要である。さらに実際にデータをサーバに渡して結果のデータを戻してもらうには、データをコピーするオーバヘッドが余分にかかる。モノリシックカーネルでは、クライアント(ユーザー空間)の持つバッファにあるデータに直接アクセス可能である。
したがってマイクロカーネルシステムには性能問題が潜在している。実際、MachやChorusOSといった第一世代のマイクロカーネルを採用したシステムの性能は低かった。しかしヨッヘン・リートケはMachの性能問題は設計と実装がまずかったためであることを示し、特にMachがページキャッシュ(英語版)を使いすぎていることを指摘した。リートケは自身のL4マイクロカーネルを注意深く設計・実装することで、特に極小原則に従えばIPCコストをMachの10分の1以下にできることを証明した。
プロセス間通信 (IPC) とは、プロセス間の通信を可能にする何らかの機構であり、メッセージ送信がよく使われる。共有メモリも厳密にはプロセス間通信機構の一種だが、マイクロカーネルでIPCといえば一般にメッセージを指す。IPCにより、OSをサーバといういくつかの小さなプログラムで構築することができ、IPCを使ってサーバを他から呼び出すことができる。周辺ハードウェアのサポートもそのように実装でき、サーバにはデバイスドライバ、ネットワークのプロトコルスタック、ファイルシステム、グラフィックスなど様々なものがある。
IPCには同期式と非同期式がある。非同期IPCはネットワーク通信に似ている。送信側はメッセージを発行して処理を継続する。受信側はメッセージの到着を定期的にチェックするか、何らかの検出機構で通知される。非同期IPCではカーネルがメッセージ用のバッファとキューを管理しており、バッファオーバーフローもカーネルが扱う。また、メッセージは2回コピーされる(送信側からカーネル、およびカーネルから受信側)。同期IPCでは、送信側か受信側はもう一方がIPC可能となるまでブロックされる。バッファリングも複数回のコピーも不要だが、明示的に両者が待ち合わせる必要があるため、プログラミングに巧妙さを必要とする。多くのプログラマは非同期送信と同期受信を好む。
第一世代のマイクロカーネルは一般に同期IPCも非同期IPCもサポートしていたが、その性能は悪かった。