[b-free: 305] Re: re: About Memory Manager

Naitoh Ryuichi (night@bfree.rim.or.jp)
Thu, 1 Jun 1995 00:09:07 +0900

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

>> On Mon, 29 May 1995 23:51:00 +0900, 藤永清和 <NBA01614@niftyserve.or.jp> said:

>  ご指名を受けましたメモリマネージャ担当の藤永です。

>  隆一さんの仰るとおり、スワップエリアは、ファイルシステム内に含めるものと考え
> ております。

>  [スワップ領域(ファイル)]
>  スワップ領域は、システム構築(インストール)時に割り当てる(たぶん2次記憶装
> 置のうちで一番速いものを使うのが望ましいのでしょうが)。

確かにスワップ領域については、速度が重要になってきますから、一番入出力
速度が速い媒体を使うべきだと思います。
ただ、OS がそれを自動的に判別するのは難しいですから、何らかの方法でユー
ザがスワップ領域を指定する必要があります。

>  メモリ管理としては、スワップ領域は、どんな媒体にあろうと感知せず、ファイルと
> してアクセスしてよいのではないでしょうか? ファイルマネージャ様いかが?
>  ページイン、ページアウトのためのインターフェースを決めねば。

>  [プロセスのメモリ]
>  プロセス固有のメモリ空間には、つぎの5種類が有る。
>  コード領域 = 命令と定数。(ページアウトしない)
>  データ領域 = 関数の外で宣言された変数と、関数内の静的変数。
>  ローカルメモリー領域 = ヒープ領域。動的に管理される。
>  スタック。
>  共有メモリ。(他のプロセスとのメモリ共有)

>  [データ領域]
>  BTRON1プログラミング標準ハンドブックp1ー62の6行目の段落「・・・ロ
> ーカルメモリ領域の大きさは固定である」は、誤植でしょうね。

永代さんもおしゃっていましたが、この部分はプロセスが取得できるローカル
メモリ領域の最大の大きさが固定ということでしょう。
その前後の文を読むとローカルメモリ領域のサイズは実行ファイルをリンクし
たときに指定した大きさと書いてあります。また、プロセス生成時にはローカ
ルメモリ領域には実際のメモリは確保しないとも書いてあります。この2つか
らみて、BTRON1 の仕様ではローカルメモリ領域の最大サイズをあらかじめユー
ザが指定しておいて、OS は最大サイズに達するまで実メモリを割り当てるよ
うになっているのでしょう。

ただ、B-Free OS では次の 2 つの理由からこのような方法をとるべきではな
いと思います。

1) B-Free OS は仮想記憶をサポートしている。
B-Free OS では、アプリケーションが一定時間アクセスしない仮想メモリ
は 2 次記憶装置にページアウトしてしまいます。一定のサイズ以上の実メ
モリは圧迫しません。

2) アプリケーション製作者があらかじめプログラムがどのくらいのメモリを
使うのかを知るのは困難。

推察するに BTRON1 では 80286 という CPU を前堤にしたおかげで、仮想記憶
が不自由になってしまい、このような苦肉の策をとったのではないでしょうか?

>  プロセス生成時にメモリが割り当てられるか否か判定する必要があるでしょうか?
>    (他のプロセスがメモリを消費していて、残り少ないときなど)
> 仮想空間のデータ領域の範囲内で大きな配列を宣言して実際にはとびとびのメモリし
> か使わないことも考えられますが・・・

プロセス生成時についてはメモリを割り当てられるかは判定する必要はないと
思います。というより、メモリが割り当てられるかどうかを判定するためには、
実行前に割り当てられる最大サイズを指定することが必要になってきます。
前の文で書いたように、アプリケーション製作者があらかじめアプリケーショ
ンがどれくらいメモリをつかうのかあらかじめ知るのは難しいですから、最大
メモリサイズを指定するのはやめた方がいいと思います。

>  [ローカルメモリ(ヒープ)]
>  get_lmb()はmalloc()、rsz_lmb()はrealloc()、rel_lmb()はfree()に相当する(詳細
> や戻り値はちがう)。

>  [スタックとサブタスク]
>  サブタスク(プロセス内タスク)のスタックは、そのプロセスのスタックエリアから
> 確保するわけですが、そのとき、箇々のタスク生成時にスタックサイズを指定する必要
> はないでしょうか?
>  1プロセスにタスクが一つのときはスタック4MB全部割り当てられますが、複数タ
> スクの場合には、タスク数が増えると1タスクあたりのスタックが減ります。たいてい
> は数十KBあれば良いのでしょうが・・・

ITRON システムコールの仕様ではタスク生成時にスタックサイズを指定するこ
とになっています。
もっともこれは、カーネル部分つまり、ITRON システムコールを処理するとこ
ろで使用するメモリなので、ユーザモードで動くときには別のスタック領域を
確保しないといけないですね(この部分は、プロセスマネージャと LOWLIB が
行うわけですが)。
私の考えとしては、ユーザモードのスタック領域については成長できるように
しておいて、割り当てた実メモリを越えた領域をアクセスした場合には実メモ
リをその都度割り当てるようにするのがいいと思います。

私は、4M バイトのサイズのスタックというのはその成長するときの最大サイ
ズという意味だと思っているのですが、真鍋さんはそのような意味で書かれた
んでしょうか?

> 付記:メモリ管理について、まだ煮詰まっていないし、勉強しなければならないことが
> 多いのですが、6月に入ったらkernel-mlのほうで議論をはじめますのでよろしくお願
> いします。

お待ちしています ^^)。

-- 
内藤隆一 (ggc00661@niftyserve.or.jp/night@bfree.rim.or.jp)