[b-free: 222] Re: About memory manage

内藤 隆一 (GGC00661@niftyserve.or.jp)
Sun, 09 Apr 1995 00:58:00 +0900

隆一です。

B-Free メイリングリストの皆さん、こんにちは。

>> On Thu, 06 Apr 1995 00:02:00 +0900, 真鍋さん said:

>  内藤様、木元様、実行ファイルの読み込み処理について、以下のような仕様は
> どうでしょうか。(と言っても、OpenVMSの仕様をかなり参考にしていたりする
> 。)

ということなのでで、このメイルは OS シリーズの Open VMS を見ながら書い
ています。
ちょっと、批判的に書いてありますが別に他意はありませんので念のため。

# もし、気にさわったのならば申し訳ありません > 真鍋さん

> ●メモリー上での実行ファイル(コード領域)の取り扱い
>  論理アドレス空間上には、大別して次の領域があります。
>   ・コード領域
>   ・データ領域
>   ・スタック領域
>  (・イメージ領域)
>  この中で、データ領域とスタック領域については内容が変化するため、ページ
> アウト処理を行う際には、原則的にはディスク上のスワップ領域に待避させる必
> 要があります。
>  一方、コード領域は書き換え不可能な領域であり、その内容(実行ファイル)
> は既にファイルシステム上にアプリケーションファイルとして存在していて、ペ
> ージイン処理が必要な場合には、アプリケーションファイルから対応するページ
> を再度読み込む事が出来ます。従って、コード領域はページアウトを生じた場合
> でも、その内容をディスク上のスワップ領域に待避する必要はありません。
>  アプリケーションファイルの実行プログラムレコード本体が、ディスク上にク
> ラスタ単位で記録されているものとすれば、上記の処理は容易に実現できると思
> います。

この場合クラスタ単位で記録されている、というのは実行ファイルをメモリの
ページサイズに合わしてディスク上に記録することを示しているわけですね。
それならば、今のコンパイル/リンカは、ページサイズ単位でコード部分とデー
タ部分に分けてありますから大丈夫です。

>  最初にアプリケーションを起動する際には、コード領域を示すページテーブル
> を作成します。同時に、各ページに対応するディスク上のクラスタを記録するテ
> ーブルも作成します。ここに記録されるクラスタ番号(ディスクユニット名も含
> む)は、実行プログラムレコードが存在するディスク上のクラスタ番号とします
> 。
>  この様に、コード領域の各ページに対応するディスク上のクラスタ番号をテー
> ブル上に記録すれば、実行ファイルの読み込み処理は終了です。あとは、プログ
> ラム実行時に、各ページのページイン処理が行われる事になります。

ディスク上のクラスタを記録するテーブルを作成するということは、メモリマ
ネージャはコード部でメモリフォールトした場合、ファイルマネージャを通さ
ずに、デバイスドライバを通してデバイスにアクセスするということでしょう
か?

このようにした場合、コード部分の内容はディスク上でもクラスタ単位で記録
する必要があります。BTRON1 のファイルシステムだとブロックサイズ以下の
断片ブロックというのがありますから、クラスタ単位にコード部を記憶するの
はなかなか難しいような気がします(リンカが実行ファイルを作るときに意識
しなければいけない)。BTRON1 ファイルシステム以外のファイルシステムも記
録単位としてページサイズを基にするとは期待できるとは限らないのではない
でしょうか?

コード部の情報については、実行ファイルを示す情報と実行ファイル中のオフ
セットの記録だけでいいと思いますが、どうでしょうか?

>  データ領域、スタック領域については、各ページに対応するディスク上クラス
> タ番号として、スワップ領域のクラスタ番号を与える事になります。この場合も
> 、一度にスワップ領域を確保するのでは無く、そのページのスワップアウト処理
> を初めて行う時になってから領域を確保する方式が良いと思います。

領域を確保するのがページのページアウト処理を行うときの方がいいという理
由は何でしょうか?

# もし、領域を確保する必要がないという理由がディスクをアクセスする時間
# を省略するためだとすると、まだ使っていない領域については、スワップ領
# 域を確保する処理はメモリ中のみで行いますから別に取っても無駄な時間は
# それほど消費しないと思いますが。。。

>  イメージ領域とは、例えばフォントファイルの様に基本的に内容が変化しない
> データの事です。この領域もコード領域と同様の処理を行うことで、スワップ領
> 域を消費する事なく、大規模なフォントファイルも論理アドレス空間に割り当て
> ることができるでしょう。

これは、フォントファイルをメモリにマップした場合のことを指しているので
しょうか?
とすると、メモリマップドファイルの場合、ファイルの実体をスワップ領域に
コピーすることはないですから、問題はないと思います。

それと、今の GCC はプログラムが変更しないような情報はコード部に記録す
るようになっています。たとえば、プログラム中で変更しない文字列について
は、関数と同様にコード部に記録します。

# 任意のファイルの内容を仮想メモリ空間にマッピングした場合、ファイルをマッ
# ピングしている論理メモリ領域の内容を変更するということは、ファイルの内
# 容を変更することも期待しているはずですから、スワップ領域にコピーしてファ
# イルの内容を反映しないというのは、プログラムから見るとまずいでしょう。

-- 
内藤隆一 (ggc00661@niftyserve.or.jp)