メモリレスアーキテクチャを簡単に言うと、mallocやfreeの下請けとなるようなAPIがない、という事に尽きます(C言語のライブラリとしてmallocやfreeがないというわけではないです。後述の方法で相当するものを作っています)。そもそも「メモリ」という概念がAPIの中にないのです。あるのはファイルに対する操作だけです。
OSASK[2]のAPIにあるのは、「ファイルを作れ」「ファイルをメモリマップしろ」「ファイルのサイズを変更しろ」などだけです。 100MBのワークエリアがほしいのなら、"WORK.BIN"というファイルを作って、それを100MBにリサイズし、適当にメモリマップして、後はあたかもそこをmallocしたかのように扱えばいいのです。この領域がいらなくなったら、メモリマップをやめて(メモリ空間からはがして)、"WORK.BIN"を削除すればおしまいです。
OSASK[2]ではstatic変数やスタックさえも、所詮はファイルなのです。メモリなんて概念上は全く存在せず、あったとしてもただのファイルキャッシュです。僕たちがCPUのキャッシュサイズ以上のワークエリアを簡単に利用できるのと同じように、ファイルシステムが許す限り、実メモリ以上の容量のワークエリアを自由に利用できます。
なお、このやり方をまともにやるとやたらとファイルアクセスが発生しそうで遅そうですが、遅延書き込み[3]やプリロード[4]などにより、実際のアクセスはかなり少ないと思われます。ファイルを生成しても遅延書き込み時間中はディスクに反映されませんし、その反映されない間にそのファイルが消去されたりすれば、結局ディスクアクセスはゼロになります。そういう感じです。
このメモリレスアーキテクチャのメリットは、メモリをコントロールするためのAPIファンクションを用意しなくていいということが、最大です。これによってOSの構造は単純化されます。 OSはスワップ[5]ファイルの管理のためにコードを追加する必要は全くなくなります。ひたすらファイルキャッシュ[6]制御の質を高めていけばそれでいいのです。またアプリごとにメモリイメージ[7]がファイルとなってきれいに分離するために、デバッグの場合はそのファイルを覗いたりいじったりすればよく、タスクセーブ[8]もこれらをまとめればメモリイメージのことは解決するということもあります。
メリットはこの程度です。今までできなかったことができるようになるというほどのものではありません。しかし効率重視のOSASK[2]にとってはこういう改善の積み重ねが重要なのです。
(This host) = http://osask.net