YOYUとマイクロカーネル —— 理想の実行環境への憧憬

YOYUは、構文解析処理系のインフラでありながら、設計の根底には「処理単位をフィルタとして分離し、パイプでつなぐ」Unix哲学がある。だがこれは、単なるプログラム構造の話では終わらない。

UNIXが進化し、Linuxが普及し、ようやく一般ユーザが本物のマルチプロセス環境を手にできるようになった時代にあって、YOYUが目指す構文処理系もまた、**無限入力／無限出力を前提とする本物の「フィルタ」**でなければならない。

本来ならば、構文処理の各段階（トークナイズ、構文構築、意味解析、コード生成など）は、それぞれが独立したプロセスとして、非同期かつ並列に動作し、マイクロカーネル的なOSの上で高速かつ確実に接続されるべきである。つまり理想的には、YOYUの各段階は別々のタスクとしてスケジューリングされ、それらはメッセージパッシングによって疎結合に協調するよう設計されるべきである。

L4への嫉妬とリスペクト

このような理想は、実はすでに一度実装されてしまっている。それがL4マイクロカーネルである。

L4のIPCはあまりにも高速で、タスク間通信のために劣化版コンテキストスイッチを意図的に発生させ、実際のハードウェアの命令セットを徹底的に最適活用してしまった。この設計によって、L4は「マイクロカーネルは遅い」という通説を打ち破り、「メッセージパッシングこそが高速である」という真逆の事実を提示してしまった。

さらにLinuxをL4上で動かすという実験的な試みにおいても、その実行性能はネイティブと比べて数％しか劣化しなかった。これは、マイクロカーネル型OSが現実のアプリケーションとスループットを両立できることを、技術的に証明してしまったに等しい。

正直に言えば、「あーうらやましいっ！俺がやりたかった！！」という言葉しか出てこない。思いついて、でも実装しきれなかった設計が、実際に成果を出してしまったこの事例は、「お前の勝ちでいいよ」と言うしかないほどの完成度を持っている。

フィルタとは何か —— mapfile()時代からの脱却

かつては mapfile() のような関数を作って、一度にすべて読み込み、一度にすべて処理し、一度にすべて出力するというアプローチが主流だった。シングルタスク環境ではそれも合理的で、CPUとメモリを最大限に使えた。

しかし現代において、その手法はあまりにもみっともない。フィルタは「無限入力・無限出力」であることが前提であり、バッファリングや一括読み込みではなく、逐次的かつ持続的な処理こそが重要になる。

そのような考えを推し進めた先にあるのが、「全段階を接続可能な構文処理系」であり、それを支えるOS設計としてL4のようなマイクロカーネルは最も理想的な舞台装置となる。

将来像としてのOSサーバ上のYOYU

もしOSが本当の意味でマイクロカーネル化され、MachのポートやL4のIPCが当たり前の世界になれば、YOYUは各ステージを完全に分離し、カーネル外のアプリケーションとして連携する構文処理系へと進化することができる。

現在はまだ、stdin から stdout へ文字列をフィルタ的に渡すような、原初的な形でそれを模倣しているに過ぎない。けれども、**「いつかこの構文処理器を本当のOS上で、プロセス同士の対話によって動かしたい」**という思いは、YOYUの産みの苦しみの根底にある。