第 224 回 PTT のお知らせ

　東横線日吉駅慶応大学側の出口(東側)を出て，東横線に沿って左(渋谷方向)
へ行く． 仲の谷という交差点(仏具屋が目印)を右に(中華料理屋と民家の間の
道)曲がり，3〜4分で理工学部の表札が見えるので，そこの左手の坂を登る．
教室は25棟の6階の
25-601 教室．
　日吉駅からの理工学部キャンパスまでの案内図は

ここ
やここにあります．

　UNIXのようなOSの下で実現されるガーベージコレクタ
(以下GCと略記)は、自身がシステムからどれだけの実メモリを
割り当てられているか、あるいは現在システムにどの程度のメモリ
の余裕があるのかを知ることができない。このため、ヒープ領域を
多くとり過ぎてページ違反を頻発し、アプリケーションの対話性を
損なったり、逆にシステムにメモリが十分に余っているにもかかわ
らず小さなヒープ領域で計算を行なってGCを頻発させたりする可能
性がある。
　本論文では、システムが持っている実メモリの量を把握すること
が、どれだけGCの効率の向上に貢献するかについて検討する。また、
そのような機構を実現するために、OSと各プロセスのメモリ管理
機構の関係はどうあるべきかについても言及する。

ありません．駅前(大学の反対側)にハンバーガ店等あります．
駅の東急デパート1階でも弁当など売っています．

第 224 回 PTTメモ

	UNIXなどのOSは、基本的に実メモリの管理をOS側が一括しておこなっ
ており、実メモリをどこに貼り付けるかということに関してユーザが口を出す
ことがほとんどできない。

	このことは、ヒープをUNIX上に実装する上で大きな障害となりうる。
すなわち、UNIX側がヒープの動作を知らないために、必ずしも必要のないペー
ジスワップを引き起こし、アプリケーションのレスポンスを悪化させたりする
ことが考えられる。

	また、コピー式のごみ集めには、ヒープが広いほどごみ集めの効率が
あがるという通説がある。この考え方に即して考えれば、コピー式のごみ集め
を利用するヒープにシステム上の余っている実メモリを全てつぎこむことがで
きればそのヒープのメモリ管理のコストを小さくできそうである。したがって、
ヒープの側としてはシステム側に対して「あまっている実メモリをみんな貸し
て」といいたいところである。ヒープ中のオブジェクトは全て生きている訳で
はないし、またコピー式のごみ集めでは空き空間は連続した空間にとられるこ
とから、システム側が「さっき貸したのを返してくれ」と要求してきた場合に
は、空きメモリの塊が残っていればそれをそのまま返せるし、最悪でもごみ集
めを行なえば相当量の返却を行なうことが可能になるはずである。しかしなが
ら、UNIXを始めとする多くのOSではヒープとOSの間にこのような実メモリに関
する貸借契約を結ぶことを許さない。

	ここにあげた他にも、メモリモデルなどの不一致などからヒープが泣
かされるケースは多い。そこで、もしOSが与える制約からはなれて既存のハー
ドウエアを存分に使えたら、どれほどヒープの効率をあげることができるかと
いうことについて述べた。具体的な方策としては、実メモリのより効率的なア
ドレス空間上へのマッピングや、ごみ集めのアルゴリズムをより効率的に動作
させることが可能なメモリマップの提案などがあげられる。

	また、このようなヒープの存在を許すためには、プロセス側とヒープ
側にどのような実メモリの取引のためのプロトコルが必要になるかという点に
ついても言及した。

	今後の課題としては、実際にOSの上に実装し、この方式がどの程度利
益をもたらすのかという点について評価を与えることが考えられる。

質疑応答:

 和田: 世代別GCの旧世代, 新世代の切り替えがGCのタイミングという偶然で
決まるのは, しょうがないのか? アプリケーションのプログラマが明示的に指
定する方がいいのではないか?

(発表者)
	御説ごもっともでございます。メモリ管理のコストの点から述べれば、
	そのような指示をアプリケーション側からもらえればより的確なオブ
	ジェクトの管理を行なうことができ、理想的です。

	ただ、それを行なうにはアプリケーションプログラマの負担の増加が
	代償として必要となります。

 多田: 横で行列の計算をしているようなものが動いている時は, こういうポ
リシーで運営できるのか. Lispマシンならいいけれども, Unixのようなヘテロ
なシステムでは?

(発表者)
	我々が発表致しました方式は、余っているメモリが存在する時に、そ
	れを活用することが、一つの主眼なっております。従って、本質的に
	メモリが不足しているような状況下で動作が効率的になるかという点
	につきましては、確かに疑問が生じます。

	ここで問題となるのは実メモリの割振りをどのようにするべきかとい
	うことです。その点に関しましてはプロセスの優先順位などを含めて
	計算を行なうことになると思いますが、実際にうまくいうのかどうか
	は今後の実装と評価をお待ち下さい。

 伊地知: SML/NJ はポータビリティ重視なので比較として不適当なのでは
(発表者)
	我々が提案致しました方法と、SML/NJの方法の比較におきましては、
	我々が提案する方法の、ページの張り付け方の最適化の部分を除きま
	しては、オブジェクトの配置の仕方の戦略(世代数、型によって配置
	する空間を変えないなど)を揃えるなどの配慮をしており、これはこ
	れで適当であると考えます。

	より効率的なGCとの比較は、今後の見当課題とさせて頂きます。

 田中: リアルタイムUnixとの関係は
(発表者)
	本研究はもともと実時間ごみ集めの研究の一環として考え付いたもの
	です。

 多田: スワップを忌み嫌っているが, 本当にGCの回数が増えるよりはスワッ
プした方が良い場合もあるのでは?
(発表者)
	デマンドページングは多数のプロセスが走っている場合には確かにトー
	タルのスループットを確保しますが、我々が普通にワークステーショ
	ン上で作業している場合には、むしろほんの幾つかのウインドゥ(例
	えばエディタ)に注目していることが多いと考えます。

	このように考えますと、スワップの間 CPUがよその仕事をできるから
	スワップの時間はそれほど問題でない、というふうに議論を進めるよ
	りも、むしろ現在ユーザが注目しているプロセスのレスポンスをあげ
	た方がユーザの使用感は向上するものと考えます。

 前野: 4Mのヒープで評価するのは小さすぎる
(発表者)
	今回の試験対象となったアプリケーション(エディタとゲーム)には 4M
	というヒープ空間は十分に広い物という判断の元にこのヒープサイズを
	選択したのですが、今後より広いヒープを必要とするようなアプリケー
	ションの挙動についても調査をしたいと思います。

 和田: Lispは何でもありだが，MLはゴミになるタイミングが分かるのではないか?

(発表者)
	MLという言語については、静的にオブジェクトの寿命を解析してをス
	タックでメモリ管理を試みた論文もあります。

	ただし、スタックにしたからすなわちメモリ管理のコストが小さくな
	るかと申しますとそれは必ずしもそうとは申し上げられません。
	(ref. A. W. Appel, "Compiling with Continuation", Cambridge
	 Press, 1992)

 伊地知: 元々MLはLispを引いているので, Lispとそれほど挙動が変わらない
のではないか?

(発表者)
	MLでは型による制約があること、値の変更が基本的には許されないこ
	と、またオブジェクトの大きさが一定でないことからプログラムの実
	行中に生成されるオブジェクトの種類についてLispとは違う点が多い
	です。

 多田: シミュレーションの結果をもう一度説明し直して欲しい

(発表者)
	シミュレートは、SML/NJの方式が、固定長のヒープ(この全域に実メ
モリが貼ってある)でメモリ管理を行なうものとした。これに対し、我々が発
表した方式ではもらう実メモリの量は同一なのだが、これを貼りつける位置を
最適化できるようにした。