[b-free: 232] Re^5:About memory manage

真鍋 裕一 (NBG02534@niftyserve.or.jp)
Tue, 11 Apr 1995 00:06:00 +0900

> ファイルシステムマネージャは、デバイスをファイルシステムに接続
> するときに、他の処理にはデバイスをアクセスできないようにロック
> を行うと思いますが、その点はどうお考えでしょうか?
> それと、ファイルシステムを介さずにメモリマネージャが直接デバイ
> スにアクセスした場合、ファイルシステム側からみると実行ファイル
> をアクセスしているもの(プロセス/周辺核)がいないということにな
> り、実行中の実行ファイルの内容が変更されてしまうという危険性は
> ないでしょうか?
>
> VMS の場合には、どうも OS にはファイルシステムというものがな
> く、ライブラリでファイルシステムを管理/構成しているようで、この
> 問題はないみたいですが。(この辺の理解にはちょっと自信がない。。。)
あらためてVMSの解説を読むと、I/Oサブシステムというマネージャに相当する
プログラムを通じてディスク入出力を行っていますね。(通常のディスクI/Oと
は別の要求受付口が存在し、高速に処理を行うとある)
 メモリマネージャがデバイスを直接操作すると、プログラムとしての信頼性が
メモリマネージャとファイルマネージャの両方に要求されるなど、難点の方が多
くなると思われるので、メモリマネージャがデバイスを直接操作する案は撤回し
ます。
 これに伴って、アプリケーションの実行コードをクラスタ単位にアクセスする
案も撤回します。

> それに、回復処理にかかる時間にしても、実行ファイルが頻繁に実行
> されるとするとファイルシステムのキャッシュに残る可能性が高くな
> ります。逆にファイルシステムを介さないとキャッシュを介せなくな
> りますから、むしろ遅くなる場合がでてくるでしょう。
 このあたりについては、メモリマネージャのページメモリ管理の中で、キャッ
シング効果を発揮するような渾然一体とした機構が実現されるものと、勝手に想
像していました。(^^;
(VMSはページ領域管理のなかで、ディスクキャッシュと同様な効果を生み出して
います。WinNTのNTFSでは、キャッシュファイルを仮想空間にマッピングすると
あり、詳細はわかりませんが仮想メモリを利用してディスクキャッシュを実現す
るらしい。)

> それとも、ページフォールト時に仮想メモリを確保するということを
> 意味しているんでしょうか?
> そうした場合、本当に仮想空間が足りなくなるというのはメモリをア
> クセスした時にしか分からないという問題があります。
> つまり、ユーザプロセスから見ると確保したはずのメモリをアクセス
> すると、(仮想空間が不足して)メモリアロケートエラーになるという
> ことになります。
> こういう方式というのは、ユーザプログラムから見てかなり使いにく
> いシステムのような気がします。
 その方法を考えていました。
 スワップ領域は必要十分な大きさがあり、その使用割合が一定の割合を越えた
時点で、何等かの警告を発生させる程度で考えていました。
 ギリギリの状況だと、スワップを確保しようとした時点で突然にプロセスが停
止するケースもありますから、プログラムから見ると確かに不親切ですね。

真鍋 裕一(NBG02534@niftyserve.or.jp)