JP2000099351A

JP2000099351A - プログラム制御装置とメモリ割当装置および方法

Info

Publication number: JP2000099351A
Application number: JP11200345A
Authority: JP
Inventors: Mitsuaki Hirono; 光明廣野; Kazuyuki Inui; 和志乾; Yoshiharu Konaka; 義治小中; Hiroshi Kuribayashi; 博栗林
Original assignee: Omron Corp; Omron Tateisi Electronics Co
Current assignee: Omron Corp
Priority date: 1997-11-21
Filing date: 1999-07-14
Publication date: 2000-04-07
Anticipated expiration: 2018-09-14
Also published as: JP3826626B2

Abstract

(57)【要約】【課題】マーク＆スイープ法でありながらインクリメ
ンタルなＧＣを実現する。コンパクションを不要とし、
且つメモリの使用効率を向上させる。オブジェクトごと
の寿命を考慮してフラグメントを低減し、メモリの使用
効率を向上させ、ＣＰＵパワーの無駄を削減する。【解決手段】メモリのヒープ領域内の、どのオブジェ
クトからも参照されないオブジェクトを検出し、そのメ
モリ領域を他のオブジェクトのメモリ割り当て可能なフ
リー領域として解放するガベージコレクションスレッド
をインクリメンタルに行う手段と、スレッドの優先度に
応じて各スレッドを時分割に実行するためのスケジュー
リングを行う手段と、前記ガベージコレクションスレッ
ドの優先度をガベージコレクションスレッド以外のスレ
ッドの優先度より高い状態と低い状態とに交互に変更す
る手段とを設ける。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、コンピュータの
プログラム制御装置、メモリ割当装置およびそれらの方
法に関する。

【０００２】

【従来の技術】先ず、本願発明の明細書において用いる
各種用語の定義を以下に示す。尚、出典記号は次のとお
りである。

【０００３】ＪＩＳ：ＪＩＳ工業用語大辞典第４版（日
本規格協会刊）参１：情報技術用語事典（オーム社刊）参２：情報処理用語大事典（オーム社刊）参３：先端ソフトウエア用語事典（オーム社刊）参Ａ：SUPER ASCII Glossary Help on Internet (1) プロセス(process) ：処理や過程を意味する一般用
語（参２） (2) スレッド(thread)：プロセスまたはタスクと呼ばれ
る１つの実行環境の中で並列実行可能な処理を複数に分
割した場合に、プロセッサのスケジュール対象となる実
行単位または制御フローのこと。（参３） (3) コンテキスト(context) ：（オブジェクト指向シス
テムに関連して）メソッドを実行するために必要な情報
を蓄えるオブジェクトをいう。コンテキストは、呼び出
し先のコンテキスト、プログラムの入ったメソッドオブ
ジェクト、プログラムカウンタ、スタックポインタとい
う情報、引数や一時変数を取るところ、および評価スタ
ックから成立する。このような実行環境をオブジェクト
としてとるが、プロセスなどをサポートする高級言語の
特徴でヒープ言語と呼ばれる。他方ＰＡＳＣＡＬやＡＬ
ＧＯＬ６０では実行環境はスタックにとられＦＯＲＴＲ
ＡＮでは固定領域にとられる。（参１） (4) タスク(task)：多重プログラミング又は多重プロセ
ッシングの環境において、計算機によって実行されるべ
き仕事の要素として制御プログラムによって取り扱われ
る命令の１つ以上の列（ＪＩＳ） (5) ガベージ(garbage) ：どこからも参照されていない
が、生成されてしまったオブジェクト。ガベージはガー
ベジコレクタで回収する。（参１） (6) ガベージコレクション(Garbage Collection)：（オ
ブジェクト指向システムに関連して）メモリ管理の中心
となるプログラムを言う。主記憶を使いきるとメインの
計算を止め、ガーベジコレクタを動かして、もはや使わ
れていないオブジェクトを全部集める方法である。この
方法でガーベジコレクタが働くと、計算が止まってしま
うため入出力が全く反応しなくなり、実時間の応答が必
要な用途には使えない。（参１） (7) インタプリタ(interpreter) ：解釈実行を行う翻訳
プログラム（ＪＩＳ） (8) リアルタイム(real time) ：計算機外部の他の処理
との関係をもちながら、かつ外部の処理によって定めら
れる時間要件に従って、計算機の行うデータの処理に関
する用語。実時間。（ＪＩＳ） (9) オブジェクト(object)：プロシジュア（定義した手
続き）とデータの特性を結合させるエンティティ（実
体）であり、これにより計算が行われ、局部的状態が蓄
えられる。（参１） (10) クラス(class) ：同一の手続き群とデータ構造を
持つオブジェクトの集合。（参３） (11) ヒープ領域(heap area) ：プログラム実行時に必
要に応じて使用されるような作業領域。（参２） (12) スケジュールする(scheduling)：ディスパッチさ
れるべきジョブ又はタスクを選択すること。（ＪＩＳ） (13) イベント(event) ：ハードウエア／ソフトウエア
が、自分自身の状態の変化を他のハードウエア／ソフト
ウエアに通知すること。一般にこの際の通知では、イベ
ントの種類やハードウエア／ソフトウエアの状態を表す
各種パラメータをメッセージとしてまとめ、相手に送信
する。そしてイベントの通知を受けた側では、メッセー
ジのパラメータなどから適切な処理を行う。（参Ａ） (14) イベントフラグ(event flag)：タスクが１つまた
は複数の事象の発生を待ち合わせるための機能とその事
象を通知する機能とからなるタスク間同期通信機構。
（参３） (15) セマフォ(semaphore) ：複数のプロセスやタスク
を並列に処理するシステムで、各プロセス間，タスク間
の同期やメッセージ制御、割込処理を行うための仕組
み。（参３） (16) 仮想マシーン（仮想機械）(virtual mathine) ：
複数の特定のプラットホーム（ＯＳやハードウエア）に
組み込まれた、特定のプラットホームに依存しないアプ
リケーションプログラムを実行する環境。同じ仮想マシ
ンさえ提供されていれば、プラットホームが変わっても
同じアプリケーションプログラムが実行できる。

【０００４】(17) Java VM(Java Virtual Machine) ：
オペレーティングシステムに組み込まれた、Ｊａｖａア
プリケーションプログラムを実行するための環境。一般
的なプログラムは、ソースコードをコンパイルして、そ
れぞれのオペレーティングシステムに最適化した実行コ
ードを生成する、というスタイルを採る。Ｊａｖａで書
かれたプログラムも同様の手順で作成するが、コンパイ
ル後のコードは、特定のオペレーティングシステムに依
存しない中間コードの形をとる。これをロードし、各オ
ペレーティングシステムに合わせたコードに変換しなが
ら実行するのがＪａｖａ仮想マシンの役目であり、同じ
仮想マシンさえ提供されていれば、プラットホームが変
わっても同じコードが実行できるようになっている。

【０００５】(18) フリー領域(free area) ：ヒープ領
域上の使用可能な領域、未使用領域。

【０００６】(19) ノーマルスレッド(normal thread)
：リアルタイム性が要求されない処理を行うスレッ
ド。

【０００７】(20) マークテーブル(mark table)：オブ
ジェクトがどこからも参照されないか否かを調べるため
に存在するオブジェクトに１対１に対応する表。或るオ
ブジェクトに参照があることが確かめられた場合、その
オブジェクトに対応する表の欄にマークを付ける。全て
の参照関係を調べたときマークの無いオブジェクトは不
要であるので取り除くことができる。

【０００８】(21) オブジェクトの寿命(life time of t
he object) ：オブジェクトが生成され、消去されるま
での時間。

【０００９】(22) ライトバリア(write barrier) ：オ
ブジェクトへの参照関係の変更をチェックし、書き替え
が起こった場合に何らかの処理をすること。本件の場合
は、書き替えが起きたとき、書き替える参照が指してい
るオブジェクトに対応するマークテーブルの欄にマーク
を付ける。

【００１０】(23) スイープ(sweeping)：ヒープ領域上
の不要なオブジェクトを取り除く処理。

【００１１】(24) オブジェクト生成(create the objec
t) ：新しいオブジェクトを生成すること。具体的に
は、ヒープ領域の一部をオブジェクトに割り当て、内容
を初期化すること。

【００１２】(25) オブジェクト消去(delete the objec
t) ：不要なオブジェクトを取り除くこと。具体的に
は、ヒープ領域に確保してある領域を解放すること。

【００１３】(26) 参照(reference) ：或るオブジェク
トＡが別の特定のオブジェクトＢにアクセスするために
オブジェクトＢを特定する情報。具体的には、オブジェ
クトＢを指すポインタまたはインデックス。

【００１４】(27) 参照変更(chenge the reference /
reconnect the reference) ：参照を現在のオブジェク
トＢから別のオブジェクトＣに変更すること。

【００１５】さて、従来のシングルプロセッサのコンピ
ュータシステムにおいて、オペレーティングシステム上
で複数のスレッドを並行処理する場合、共有メモリを用
いて排他制御するために、また複数のタスク間で同期を
とるために、従来よりセマフォやイベントフラグなどを
用いて排他制御が行われている。

【００１６】また、例えばプログラムを少量のメモリ環
境下で動作させることなどを目的として、仮想記憶を行
わないで単一のアドレス空間のメモリをプログラムの実
行時に動的に割り当てる、いわゆる動的記憶管理が従来
より行われている。このような動的記憶管理によれば、
プログラムにより明示的にメモリ領域の解放を行わなけ
れば、プログラムの実行過程において使用されなくなっ
たメモリ領域が発生する。その結果、プログラムが使用
できるフリー領域が次第に不足する。こうした問題を回
避するために、使用されなくなったメモリ領域（ガベー
ジ）を抽出し、これらを集めて（コレクトして）再び使
用可能なフリー領域とする、ガベージコレクションと呼
ばれる処理を自動的に行うようにしている。

【００１７】ここで従来のガベージコレクションの処理
手順をフローチャートとして図５４に示す。ガベージコ
レクションのアルゴリズムにはマーク＆スイープ法、複
写法、参照カウント法などの各種方法が考えられている
が、ここではマーク＆スイープ法について例示する。図
５４に示すように、まずガベージコレクションの途中で
ガベージコレクションスレッド以外の他のスレッドが実
行されないように割り込みを禁止し、シングルスレッド
モードにする(s201)。続いてメモリ上のガベージコレク
ションの対象となる領域（以下「ヒープ領域」とい
う。）に割り当てられているオブジェクトにそれぞれ対
応するマークの記憶領域（以下「マークテーブル」とい
う。）をクリアする(s202)。続いてヒープ領域内に割り
当てられているオブジェクトの参照関係を示す情報を基
に何れかのオブジェクから参照されているオブジェクト
を検出し、それらに対応するマークテーブル上の位置に
マークを付ける処理を行う(s203)。この処理により、何
れのオブジェクトからも参照されていないオブジェクト
はもはや使われなくなったオブジェクトであり、それに
相当するマークテーブルにはマークが付けられないこと
になる。従ってそのマークしていないオブジェクトを新
たなオブジェクトの割当可能な領域、すなわちフリー領
域として抽出する(s204)。例えばこのフリー領域をリス
ト構造のデータとして生成する。その後、割り込み禁止
を解除し、マルチスレッドのモードに戻す(s205)。

【００１８】従来はこのようなガベージコレクション
が、メモリのフリー領域が所定量まで減少した時点で自
動的に起動されるようにしていた。

【００１９】また、ガベージコレクションを行ったと
き、任意の大きさ（メモリサイズ）のオブジェクトが任
意に解放されるのでフラグメントが発生する。そこで、
連続したサイズの大きな領域がとれるように、オブジェ
クトの割当領域を例えば先頭から順次詰めるメモリコン
パクション（以下単に「コンパクション」という。）を
実行していた。

【００２０】

【発明が解決しようとする課題】上述した排他制御の機
能をセマフォやイベントフラグなどのコンピュータ資源
を用いることで実現している従来のシステムにおいて
は、その資源が他のスレッドなどで使用されている場合
には、他のスレッドはその資源が解放されるのを待たな
ければならない。このような資源待ちの時間が生じる
と、リアルタイム性の要求されるシステムにおいては大
きな障害となる。すなわち、資源待ち状態にあるスレッ
ドは、その資源が解放されるまで、処理できずリアルタ
イムな応答が不可能となる。

【００２１】例えば上記従来のガベージコレクション
（以下「ＧＣ」という。）の方法によれば、メモリ空間
が広いほど、ガベージとしてコレクトしてもよい領域を
見つけ出すのに時間がかかり、例えば６４〜１２８ＭＢ
のヒープ領域で数秒間を要し、且つＧＣはフリー領域が
ある程度減少した時点で不定期に行われるので、リアル
タイム性の要求されるシステムには用いることができな
かった。

【００２２】リアルタイム性の要求されるシステムで
は、あるタスクを実行中に何らかのイベント（割り込
み）が発生すれば、そのイベントに応じた他のスレッド
を処理することになるが、そのスレッドの切替に要する
時間は、最悪値として例えば数十μｓｅｃ以下であるこ
とが要求される。ところが、上述したようにＧＣが何時
起動されるか予測できず、一旦起動されれば、ＣＰＵは
数秒間ＧＣに専念することになるため、その間リアルタ
イム処理は不可能となる。

【００２３】上述の問題はＧＣの場合に限らず、長時間
の資源待ち状態が生じるシステムに共通の問題である。

【００２４】この発明の目的はセマフォやイベントフラ
グなどのコンピュータ資源をロックのメカニズムとして
使用せずに、処理の排他性を保証することにより、上述
の問題を解消することにある。

【００２５】ＧＣの他の方法として、従来の複写法をイ
ンクリメンタルに行うようにして、リアルタイム性を確
保する方法が情報処理Vol.35 No.11 pp1008 〜pp1010に
示されている。この方法によれば、ＧＣの途中で中断を
許すことができるので、時分割的に他のスレッドと並行
処理することが一応はできる。しかし、この複写法をイ
ンクリメンタルに行うようにする方法では、複写中に他
のスレッドがメモリを使用する訳にはいかないので、メ
モリを使用しない極一部のスレッドしか並行処理できな
い。また、複写法では、複写元と複写先のメモリ領域を
確保しておかなければならないので、メモリの使用効率
が低く、少量のメモリ環境下で動作させるシステムには
向かない。

【００２６】また、マーク＆スイープ法でマルチスレッ
ドに対応するために参照関係が変更される度にマークを
付与する方法は、「On-the-fly GC 」という名前で、Ｇ
Ｃ専用のＣＰＵに処理を割り当てるマルチＣＰＵ化のた
めの方法が情報処理Vol.35 No.11 pp1006 〜pp1008に示
されている。しかし、この方法では、オブジェクトが常
に作成されて、且つ参照関係が変更されている場合に、
既にマークしているツリーを何回も辿り直して新しいノ
ードを見つけてマークしなければならず、マーク作業が
いつまでも終わらない場合が生じたり、非常に長い時間
がかかる、という問題があった。また、この方法ではス
イープ中にシステムをロックする必要があった。

【００２７】そこで、この発明の他の目的はマーク＆ス
イープ法でありながらＧＣスレッドを他のスレッドと実
質的に並行処理可能とし、ＧＣの任意の時点で中断して
も短時間に確実にＧＣを完了できるようにしたインクリ
メンタルなＧＣを可能とすることにある。

【００２８】また、従来のマーク＆スイープ法等のＧＣ
によるフラグメントを解消するためにコンパクションを
行う際、多大なＣＰＵパワーを必要としていた。また、
このコンパクションを行わなければメモリの使用効率が
低下するという問題があった。

【００２９】この発明の他の目的はコンパクションを不
要とし、且つメモリの使用効率を向上させることにあ
る。

【００３０】さらに、従来のオブジェクト指向システム
においては、永続的に存在する寿命の長いオブジェクト
と短時間で消滅する寿命の短いオブジェクトがヒープ領
域内に混在していたため、ＧＣを行うと、短寿命のオブ
ジェクトから消去されて確実にフラグメントが生じてメ
モリ使用効率が急に低下する。また、ＧＣを行う場合
に、永続的に存在するオブジェクトに対してもガベージ
であるか否かの判定を毎回行わなければならないので、
このことがＣＰＵパワーの無駄となっていた。これに対
して、一定期間存在していたオブジェクトを永久に存在
するものと見なして、そのオブジェクトを存在調査から
外す、いわゆる世代別ガベージコレクションという方法
も従来から考えられているが、このような方法でも不要
なオブジェクトが存続したり、それぞれのオブジェクト
について一定期間の存続調査をしなければならないとい
う欠点があった。

【００３１】この発明の他の目的はオブジェクトごとの
寿命を考慮してフラグメントを低減し、メモリの使用効
率を向上させ、ＣＰＵパワーの無駄を削減することにあ
る。

【００３２】ここで、先行技術調査を行った際に発見し
た文献と本願発明との関係について示しておく。

【００３３】(1) Incremental Garbage Collection of
Concurrent Objects for Real-TimeApplication この論文はBaker が書いたという1978年のリアルタイム
ＧＣに対して、全体の処理時間から必要なＧＣの処理時
間の割合を求めるものである。本願発明に係る課題を解
決するものではない。

【００３４】(2) Distributed Garbage Collection for
the Parallel Inference Machine:PIE64 ＧＣを行う領域を細かく分けることにより、個々の処理
時間を短くしてリアルタイム性を向上する方法である。
本願発明のように全ての領域を対象にするものとは基本
的に異なる。また、スケジューリングについては述べら
れていない。

【００３５】(3) Garbage Collection in Distributed
Enviroment Baker の考えを発展させ、ネットワークの分散環境に適
応したもの。ネットワーク固有の問題を解決しようとす
るものであり、本願発明とは異なる。この分散環境の考
え方に、本願発明のスケジューラを組み合わせることに
より、分散環境でより高度なリアルタイムＣＧを実現す
ることも可能となる。

【００３６】(4) 特開平１−２２００３９号システムコール発行時に、そのシステムコールにより起
動されるタスクの優先度を制御するもの。優先度制御と
いう点で共通点があるだけ。

【００３７】(5) 特開平３−２３１３３３号オブジェクトのサイズを検出し、そのサイズに応じてワ
ークエリアをメモリに確保することが一応示されてい
る。

【００３８】(6) 電子情報通信学会誌Vol.80 No.6 pp58
6-592 マルチメディアオペレーティングシステムのコンセプト
が示されている。

【００３９】(7) 日本ソフトウェア科学会第１２回Ｄ７
−４スタック上のオブジェクトの一番上にオブジェクトの大
きさを書いておくことが示されている。すなわちオブジ
ェクトのサイズを記憶しておく、という点でのみ関連が
ある。

【００４０】(8) 11TH Real-Time System Symposium "I
ncremental Garbage Collection ofConcurrent Object
for Real-Time Applications" オブジェクト間の参照ツリーに類似の考え方が示されて
いる。

【００４１】(9) 情報処理学会第３８回全国大会5U-7 オブジェクトの寿命に関連してメモリ割当を行うことが
示されている。

【００４２】(10)Lecture Notes in Computer Science
259 "Garbage Collection in a Distributed Environme
nt" アプリケーションプログラムインタフェースの呼出に応
じてＧＣを制御することと、オブジェクト参照に関する
技術思想が示されている。

【００４３】

【課題を解決するための手段】請求項１，１８，２５に
係る発明は、或るスレッドからの、指定メモリ領域に対
するデータの書き込み有無検出の開始を依頼するアプリ
ケーションプログラムインタフェースの呼び出しに応答
して、その書き込み有無を示すフラグを書き込み無しの
状態に設定し、前記指定メモリ領域に対するデータの書
き込みがあったとき、前記フラグを書き込み有りの状態
に設定する。そして前記スレッドからの、指定メモリ領
域に対するデータの書き込み有無検出の終了を依頼する
アプリケーションプログラムインタフェースの呼び出し
に応答して、前記フラグの状態に応じた値を前記スレッ
ドに返す。

【００４４】これにより、コンピュータ資源をロックの
メカニズムとして使用せずに、処理の排他性が保証され
る。すなわち指定メモリ領域に対するデータの書き込み
有無検出の開始を依頼するＡＰＩの呼び出しから指定メ
モリ領域に対するデータの書き込み有無検出の終了を依
頼するＡＰＩの呼び出しまでの間で行われたスレッドＡ
の処理の途中で、他のスレッドによる指定メモリ領域に
対する書き込みがあったか否かが、そのスレッドＡで分
かる。書き込みが行われていなければ、指定メモリ領域
の排他性が保たれている。もし書き込みが行われていれ
ば、スレッドＡのその間の処理を無効にして、例えばそ
の処理を再度実行するなどの方法によって高い応答性を
保ちながら、排他制御を行うことができるようになる。

【００４５】請求項２，１９，２６に係る発明は、メモ
リのヒープ領域内の、どのオブジェクトからも参照され
ないオブジェクトを検出し、当該オブジェクトのメモリ
領域を他のオブジェクトのメモリ割り当て可能なフリー
領域として解放するＧＣスレッドをインクリメンタルに
行うスレッドを、他のスレッドの優先度より高い状態と
低い状態とに交互に変更する。

【００４６】このようにＧＣスレッドの優先度を交互に
切り替えることによって、ＧＣスレッドの優先度が低い
状態では、他のスレッドによるアプリケーションが優先
され、動作するアプリケーションが無い場合にはＧＣス
レッドが自動的に動かされ、メモリのフリー領域が自動
的に拡大される。ＧＣスレッドの優先度が高い状態で
は、他のスレッドは実行されないが、優先度の低い状態
で、他のスレッドにより、ＧＣが継続して行われないこ
とによってフリー領域が慢性的に不足状態となることが
防止され、常に高いパフォーマンスを維持することがで
きる。

【００４７】請求項３に係る発明は、前記ガベージコレ
クションスレッドの優先度の高い状態の時間をアプリケ
ーションプログラムインタフェースの呼び出しによって
設定する。これにより、ＡＰＩを呼び出す側で、たとえ
ばシステムの応答性を重視する場合には優先度の高い状
態の時間を短くし、システム全体のスループットを重視
する場合には優先度の高い状態の時間を長くする、とい
った設定が可能となり、システムのニーズに応じて性能
を変えることができるようになる。

【００４８】請求項４に係る発明は、前記ガベージコレ
クションスレッドの優先度の高い状態と低い状態による
周期をアプリケーションプログラムインタフェースの呼
び出しによって設定する。これにより、たとえば連続的
なパルスを処理するような、連続してＣＰＵ資源が必要
なアプリケーションプログラムの場合には、周期を短く
し、通常のアプリケーションプログラムのような断続的
にＣＰＵ資源を利用するアプリケーションプログラムで
は周期を長くすることによって、コンテキストスイッチ
などのオーバヘッドを小さくすることができる。

【００４９】請求項５に係る発明は、前記フリー領域の
容量の時間変化を検出し、前記フリー領域の容量が低下
傾向のとき、前記ガベージコレクションスレッドの優先
度の高い状態の時間を長くする。これにより、動的にガ
ベージコレクションの優先度の高い状態の時間を調整す
ることになり、どのようなアプリケーションプログラム
でもフリー領域が足りなくなるといった状況を回避する
ことができ、且つフリー領域が十分確保できるシステム
やアプリケーションプログラムでは、ガベージコレクシ
ョンを最低限に抑えることができる。

【００５０】請求項６，２０，２７に係る発明は、イベ
ントの発生に応じてリアルタイムスレッドを実行させ、
該リアルタイムスレッドの中断時または終了時に非リア
ルタイムスレッドを実行させるようにし、ＧＣスレッド
以外の非リアルタイムスレッドの実行によりフリー領域
が所定の値まで減少したとき、非リアルタイムスレッド
の１つであるＧＣを実行させる。

【００５１】一般にリアルタイム性の要求されるシステ
ムではリアルタイム性の必要なスレッドとそうでないス
レッドが存在していて、一般にリアルタイム性が要求さ
れるプログラムは生成するオブジェクトの量が少なく、
その量を予測して設計することができる。一方、リアル
タイム性の要求されないプログラムは、生成されるオブ
ジェクトの量の予測が困難である。そこで、リアルタイ
ム性の要求されるプログラムが生成すると予想されるオ
ブジェクトの量を定義し、リアルタイム性の要求されな
いスレッドがオブジェクトを生成して、メモリのフリー
領域の量が例えば上記定義したオブジェクトの量の近傍
にまで減少した時に、その時点でスケジューリングを行
い、ＧＣスレッドを実行させる。このことによって、フ
リー領域が直ちに確保され、リアルタイム性の要求され
るスレッドの実行可能な環境を常に維持することができ
る。

【００５２】請求項７，２１，２８に係る発明は、メモ
リのヒープ領域内の、どのオブジェクトからも参照され
ないオブジェクトを検出し、当該オブジェクトのメモリ
領域を他のオブジェクトのメモリ割り当て可能なフリー
領域として解放するとともに、前記フリー領域または前
記オブジェクトの使用領域の量に基づいて、手順の異な
る複数通りのガベージコレクションスレッドを選択的に
実行するようにする。

【００５３】一般に、ＧＣを行う場合、そのアルゴリズ
ムに応じて、ＣＰＵに要求されるパワー、メモリの使用
量、ＧＣに要する時間などがそれぞれ異なる。そのた
め、フリー領域の量に応じて、適切なＧＣの手順は異な
る。上述したように、フリー領域または使用領域の量に
応じてＧＣの手順を切り替えることによって、常に効率
的なＧＣが可能となる。

【００５４】請求項８，２２，２９に係る発明は、メモ
リのヒープ領域内に割り当てられるオブジェクトのサイ
ズの分布を検知し、その分布中心より大きな固定サイズ
の整数倍を前記ヒープ領域に対する新たなオブジェクト
の割り当てサイズとする。

【００５５】一般に、オブジェクト指向のシステムにお
いては、プログラムの実行時に生成されるオブジェクト
の大きさ（メモリ上のサイズ）の発生頻度分布は正規分
布を示す。一方、新たなオブジェクトを生成する際、メ
モリ上のフリー領域から割り当て可能な領域を抽出する
が、上述のようにオブジェクトのサイズの分布中心よ
り、大きなサイズを新たなオブジェクトの割り当てサイ
ズとしておくことによって、その割り当てられたオブジ
ェクトが消去された後、新たなオブジェクトが割り当て
られるとき、上記割り当てサイズより小さなオブジェク
トであれば再利用できる。上記割り当てサイズは正規分
布の分布中心より大きなサイズであるため、多くのオブ
ジェクトが先に使用されていたメモリ領域を再利用でき
ることになる。また、このことにより、コンパクション
を行わなくてもメモリの使用効率が向上することにな
る。また、コンパクションのためのＣＰＵパワーが不要
となり、小規模のＣＰＵで応答性の高いシステムを構成
することができる。

【００５６】請求項９に係る発明は、前記オブジェクト
のサイズの分布を検知する手段は、システムの使用開始
時にシステムに組み込まれ、前記オブジェクトのサイズ
の分布を検知した後にシステムから切り離されるプログ
ラムモジュールによるものとする。また、請求項１０に
係る発明は、前記オブジェクトの割り当てサイズを決定
する手段は、システムの使用開始時にシステムに組み込
まれ、前記オブジェクトの割り当てサイズが決定された
後にシステムから切り離されるプログラムモジュールに
よるものとする。

【００５７】これにより、一度オブジェクトのサイズの
分布が検知された後は、また、オブジェクトの割り当て
サイズが決定された後は、メモリ領域とＣＰＵパワーの
無駄がなくなる。

【００５８】請求項１１，３０に係る発明は、メモリの
ヒープ領域内にオブジェクトを生成する手段を備えたプ
ログラム制御装置において、前記ヒープ領域内を予め複
数のサイズに分割し、オブジェクト生成時に当該オブジ
ェクトのサイズより大きく且つ最も小さなサイズの領域
を割り当てる。

【００５９】請求項１２に係る発明は、前記複数のサイ
ズの分割数と各サイズを引数とするアプリケーションプ
ログラムインタフェースの呼び出しによって、前記ヒー
プ領域を分割する。

【００６０】請求項１３，３１に係る発明は、メモリの
ヒープ領域内にオブジェクトを生成する手段を備えたプ
ログラム制御装置において、固定サイズの整数倍を前記
ヒープ領域内に対するオブジェクトの割り当てサイズに
決定し、アプリケーションプログラムインタフェースの
呼び出しによって前記固定サイズを設定する。

【００６１】また、請求項１４，３２に係る発明は、メ
モリのヒープ領域内にオブジェクトを生成する手段を備
えたプログラム制御装置において、固定サイズの整数倍
を前記ヒープ領域内に対するオブジェクトの割り当てサ
イズに決定するものとし、前記ヒープ領域内に割り当て
られるオブジェクトのサイズの分布をアプリケーション
プログラムインタフェースの呼び出しによって設定し、
該アプリケーションプログラムインタフェースの呼び出
しに応答して、前記分布の中心より大きな値を前記固定
サイズとして設定する。

【００６２】これにより、別の装置、システム、および
アルゴリズムで、メモリのヒープ領域内に割り当てられ
るオブジェクトのサイズの分布を測定して、決定したオ
ブジェクトの割り当てサイズの基になる固定サイズを登
録することができ、ＣＰＵパワーとメモリの使用効率を
向上させることができる。

【００６３】請求項１５，２３，３３に係る発明は、テ
ンプレートとしてのクラスと該クラスにより生成される
オブジェクトをメモリのヒープ領域内に割り当てる際、
前記クラスからオブジェクトが生成された時刻に相当す
るデータを記憶し、前記オブジェクトを削除する際に、
当該オブジェクトの寿命を検出し、該寿命のデータをク
ラスに設け、当該クラスからオブジェクトを生成する際
に、前記寿命のデータに基づいて、前記ヒープ領域に対
するオブジェクトの生成領域を分ける。

【００６４】一般にオブジェクト指向のシステムにおい
ては、クラスをテンプレートとしてオブジェクトが生成
されるため、同一のクラスから生成されたオブジェクト
は略同一の寿命を持つ。そこで、或るクラスからオブジ
ェクトが生成された時刻に相当するデータを記憶し、そ
のオブジェクトが削除された際に、当該オブジェクトの
寿命を検出して、これをそのオブジェクトを生成したク
ラスの寿命データとして記憶し、そのクラスからオブジ
ェクトを生成する際に、寿命データに基づいて、異なっ
たヒープ領域にオブジェクトを生成することによって、
長寿命のオブジェクトと短寿命のオブジェクトが異なっ
た領域に生成される。これにより、長寿命領域でのフラ
グメントが大幅に低下し、メモリの使用効率が向上す
る。また、ＧＣを行う場合に、短寿命のオブジェクトが
生成される領域を重点的に処理することによって、ＧＣ
に消費されるＣＰＵパワーを低減することができるよう
になる。

【００６５】請求項１６，２４，３４に係る発明は、メ
モリのヒープ領域内の、他のオブジェクトから参照され
るオブジェクトを検出して当該参照の有無状態を記憶
し、当該記憶内容を基に、どのオブジェクトからも参照
されないオブジェクトのメモリ領域を他のオブジェクト
のメモリ割り当て可能な領域として解放するが、オブジ
ェクトの生成時にオブジェクトの参照関係を表すツリー
構造の第１のデータ（この第１のデータは、たとえばオ
ブジェクトの参照関係を示す、オブジェクト内に設けら
れる１つの変数である。）を記憶し、参照関係の変更時
に、オブジェクトの参照関係の変更された部分のオブジ
ェクトを示す第２のデータを記憶し、第１のデータを探
索して参照されているオブジェクトを検出し、第２のデ
ータを読み出すとともに該データを基に第１のデータを
探索して、参照されているオブジェクトを検出する。

【００６６】このように構成することにより、スイープ
やマークテーブルのクリアを行うときに、他のスレッド
を止めなくても、スイープ中またはマークテーブルのク
リア中に他のスレッドにより新たなオブジェクトが生成
されたり、オブジェクト間の参照関係が変更されても、
マークテーブルを基にスイープを行う際に、上記の新た
に生成されたオブジェクトを消去してしまうことがな
い。そのため、インクリメンタルにＧＣを行うことがで
き、また、自由に中断ができるので、リアルタイム性が
向上する。また、常にバックグラウンドでＧＣスレッド
を動作させておくことが可能となり、メモリの使用効率
を常に高く維持できる。しかも、ツリー探索によるマー
ク付与に要する時間が短縮化され、割込によって、いつ
までもマーク付与が完了しない、といった不都合が防止
でき、ＧＣを確実に実行できる。

【００６７】請求項１７に係る発明は、前記参照オブジ
ェクト検出手段は、前記オブジェクトの参照関係の変更
時の参照先が前記第１のデータの探索により初めて検出
されたオブジェクトであるときにのみ、参照先の当該オ
ブジェクトを前記第２のデータとして記憶する。

【００６８】これにより、オブジェクトの参照関係の変
更時の参照先が既にマークされている場合に、第２のデ
ータを重ねて記憶することがなくなり、第１のデータの
探索およびマークに要する時間をその分短縮化できる。

【００６９】

【発明の実施の形態】この発明の実施形態であるプログ
ラム制御装置およびメモリ割り当て装置の構成を図１〜
図５３を参照して順次説明する。

【００７０】〔第１の実施形態〕図１は装置のハードウ
エアの構成を示すブロック図である。装置は基本的にＣ
ＰＵ１とオブジェクト群を生成するヒープ領域およびマ
ークテーブル等を記憶するメモリ２、および外部との入
出力を行うＩ／Ｏ３とから構成する。また、外部から必
要なプログラムをメモリにロードする場合は、ＣＤ−Ｒ
ＯＭ読取インタフェース４を用い、プログラムが予め書
き込まれたＣＤ−ＲＯＭ５を読み取るようにする。この
ＣＤ−ＲＯＭが本願発明に係るプログラム記録媒体に相
当する。

【００７１】図２はソフトウエアの構成を示すブロック
図である。同図において、カーネル部分はＣＰＵやメモ
リを資源として管理し、時分割によるマルチスレッドの
機能を実現する。ＶＭ（仮想マシーン）部分はプログラ
ムとカーネルとのインタフェースを行うソフトウエアで
あり、ここではアプリケーションプログラムから見てＶ
Ｍ以下の階層全体が例えばＪａｖａ仮想マシンとして作
用させる。（ＪａｖａはSun Microsystems社の商標）こ
の場合、カーネルとＶＭ部分がＪａｖａＯＳを構成す
る。このＶＭにはプログラムがバイトコード等の中間コ
ードで与えられるとき、これを解釈するインタプリタと
その解釈に応じて呼び出されるプログラムモジュール等
を含む。同図におけるプログラムは中間コードによる各
種スレッドであり、上記インタプリタを介して、内部の
プログラムモジュールを実行する。

【００７２】図３はメモリのヒープ領域に生成されるオ
ブジェクトの参照関係およびスタックとの関係を示す図
である。ヒープ領域に対してオブジェクトを生成した
際、或るオブジェクトから他のオブジェクトへの参照関
係は同図に示すようにルートノードから延びるツリー構
造を成す。例えばグローバル変数を宣言すれば、その変
数に対応するオブジェクトが生成される。またスレッド
毎に引き数領域、戻り番地、ローカル変数、作業領域等
の情報を記憶するスタックが生成され、例えば図中矢印
で示すようなスタック上のローカル変数からツリー上の
グローバル変数への参照関係なども記憶される。これら
のスタックはヒープ領域外の所定領域に格納される。

【００７３】図４は図２に示したソフトウエアの構成を
ブロック図として詳細に示したものである。同図におい
て、ＧＣモジュール１０はＧＣを行うための各種処理の
プログラムモジュールであり、ＧＣスレッド１１はこれ
らのモジュールを呼び出すことによって、ＧＣを実行さ
せる。また、インタプリタ１２は、この例で、「スレッ
ド４」からオブジェクト生成依頼があったとき、ＧＣモ
ジュール１０の「オブジェクト生成」を呼び出し、また
オブジェクト間の参照関係の変更依頼があったとき、Ｇ
Ｃモジュール１０の「マーク付与」を呼び出す。

【００７４】なお、図４に示した例では、各スレッドが
中間コード（例えばＪａｖａアプレットの場合バイトコ
ード）で表されているが、中間コードをＶＭに対するネ
イティブコードに変換するコンパイラを設けてもよい。
（例えばＪａｖａの場合、ＪＩＴ(Just-In-Time コンパ
イラ）等を設ける。）この場合、ネイティブコードで記
述したスレッドであるので、図４に示したインタプリタ
１２を介さずにＧＣモジュール１０を直接アクセスする
ことになる。

【００７５】図５はＧＣを行うことによって、ヒープ領
域内に生じるフラグメントを解消するためのコンパクシ
ョンを行った例を示す図である。図中ハッチング部分が
オブジェクトであり、これをコンパクションすることに
よって、（Ｂ）に示すようにフラグメントが解消され
て、連続したメモリ空間が広がることになる。

【００７６】上記コンパクションは図４に示したＧＣモ
ジュールの「コンパクション」のプログラムにより行
う。

【００７７】図６はコンテキストスイッチ発生有無を検
出するためのＡＰＩの使用例を示す図である。同図の
（Ａ）に示すように、処理１を実行する前にコンテキス
トスイッチ発生有無の検出開始を依頼するＡＰＩ＃Ａを
発行してから処理１を実行する。処理１の終了後、コン
テキストスイッチ発生有無検出の終了を依頼するＡＰＩ
＃Ｂを発行する。（Ａ）に示す例ではこの間にコンテキ
ストスイッチが発生していないので、そのまま次の処理
２を行う。もし、（Ｂ）に示すように、処理１の途中で
スレッド＃２の処理が行われれば、すなわちコンテキス
トスイッチが発生していれば、ＡＰＩ＃Ｂの発行後、処
理１を破棄する。たとえばメモリの領域Ａの内容を領域
Ｂにコピーするような処理で、コピー処理中にコンテキ
ストスイッチが発生した場合、領域Ａの内容が変わって
領域ＡとＢの内容が不一致となる場合がある。不一致で
はコピーしたことにならないので、領域Ｂを無効にす
る。このことは、最初から処理が行われなかったのと同
じであり、処理自体を破棄したことに他ならない。

【００７８】図７は上記の処理をフローチャートとして
示したものである。まず、ＡＰＩ＃Ａを発行してから処
理１を実行する（ｓ１→ｓ２）。この処理１が終了した
後、ＡＰＩ＃Ｂを発行して、その戻り値を取得する（ｓ
３）。戻り値がコンテキストスイッチの発生を表す場
合、処理１を破棄して、再び処理１を実行する（ｓ４→
ｓ５→ｓ１→ｓ２）。戻り値がコンテキストスイッチの
非発生を表す場合、処理を終了する。このように所定の
期間内でのコンテキストスイッチの発生有無が分かるの
で、コンテキストスイッチが発生すれば、その間の処理
を破棄し無効とすることによって、システムを現実には
ロックしていないにも拘らず排他的制御を行うことが可
能となる。

【００７９】図８は上記ＡＰＩ＃ＡおよびＡＰＩ＃Ｂの
カーネルにおける処理手順を示すフローチャートであ
る。ＡＰＩ＃Ａの発行（システムコール）があれば、コ
ンテキストスイッチの発生有無を示すフラグをクリアす
る。また、ＡＰＩ＃Ｂが発行されると、上記フラグの状
態を戻り値としてスレッドに返す。

【００８０】図９はコンテキストスイッチの処理手順を
示すフローチャートである。コンテキストスイッチがス
ケジューラによって行われると、上記フラグをセットし
てからコンテキストスイッチを実行する。すなわちスイ
ッチ前のスレッドの実行状態をコンテキストとして格納
するとともに、スイッチ後のスレッドのコンテキストを
読み出してＣＰＵのレジスタ等に設定する。

【００８１】図１０は上記コンパクションの処理手順を
示すフローチャートである。先ず、ヒープ領域内の先頭
のオブジェクトを指定し（ｓ１１）、そのオブジェクト
をヒープ領域の先頭にコピーするための領域を確保し
（ｓ１２）、コピー中に他のスレッドによってその領域
に何らかのデータが書き込まれないようにしてから上記
ＡＰＩ＃Ａを発行する（ｓ１３）。そして、図５に示し
たように、ヒープ領域内のオブジェクトを先頭から順次
空き領域へコピーすることによって詰めていく（ｓ１
４）。１つのオブジェクトについてのコピーが終われ
ば、上記ＡＰＩ＃Ｂを発行する（ｓ１５）。このことに
より、ＡＰＩ＃Ａを発行してから、ＡＰＩ＃Ｂを発行す
るまでの期間にコンテキストスイッチが発生したか否か
がＡＰＩ＃Ｂの戻り値として得られる。もしコンテキス
トスイッチが発生していれば、今回コピーを行ったオブ
ジェクトを既に確保している領域に再びコピーする（ｓ
１６→ｓ１３→・・・）。もしコンテキストスイッチが
発生していなければ、次のオブジェクトについて同様に
処理を行う（ｓ１６→ｓ１７→ｓ１８→・・・）。この
ようにシステムをロックすることなく、しかも他のスレ
ッドとともに、コンパクションを同時に行うことが可能
となる。

【００８２】上述の例ではマーク＆スイープ法によるＧ
Ｃにおけるコンパクションに適用したが、複写法による
ＧＣに適用する場合、図１１および図１２に示す処理を
行う。

【００８３】図１１は上記複写法によるＧＣのフローチ
ャートである。先ず、オブジェクトの参照関係を表すツ
リー構造のデータのルートノードへポインタを移動し
（ｓ２１）、そのルートノードに相当する、Ｆｒｏｍ領
域にあるオブジェクトをＴｏ領域に複写する（ｓ２
２）。（ヒープ領域はＦｒｏｍ領域とＴｏ領域に分けら
れ、Ｆｒｏｍ領域内の残すべきオブジェクトのみをＴｏ
領域に複写することによってＴｏ領域にガベージのない
オブジェクトだけを再構成する。次回は現在のＦｒｏｍ
領域をＴｏ領域とし、Ｔｏ領域をＦｒｏｍ領域として、
その操作を交互に繰り返すのが、複写法によるガベージ
コレクションである。）その後、ツリーを辿って、参照
関係にある次のオブジェクトへポインタを移動させ（ｓ
２３）、そのオブジェクトをＴｏ領域に複写する（ｓ２
４）。この処理をツリーで辿れるすべてのオブジェクト
について行う。

【００８４】図１２は図１１における複写処理の内容を
示すフローチャートである。先ず、複写すべきオブジェ
クトをＴｏ領域内の所定位置にコピーするための領域を
確保し、コピー中に他のスレッドによってその領域に何
らかのデータが書き込まれないようにし、上記ＡＰＩ＃
Ａを発行してから（ｓ３１）、オブジェクトをＦｒｏｍ
領域からＴｏ領域に複写する（ｓ３２）。その後、上記
ＡＰＩ＃Ｂを発行する（ｓ３３）。このことにより、Ａ
ＰＩ＃Ａを発行してから、ＡＰＩ＃Ｂを発行するまでの
期間にコンテキストスイッチが発生したか否かがＡＰＩ
＃Ｂの戻り値として得られる。もしコンテキストスイッ
チが発生していれば、今回複写を行ったオブジェクトを
既に確保している領域に再び複写する（ｓ３４→ｓ３１
→・・・）。

【００８５】図１３および図１４はコンテキストスイッ
チの発生有無を検出して排他性を確保するのではなく、
複写しようとするオブジェクトが複写前に書き替えられ
たか否かを検出して排他性を確保する場合の処理手順を
示すフローチャートである。

【００８６】複写を行う場合、先ず複写すべきオブジェ
クトをＴｏ領域内の所定位置にコピーするための領域を
確保し、コピー中に他のスレッドによってその領域に何
らかのデータが書き込まれないようにしてから、図１３
に示すようにＡＰＩ＃Ｃを発行する（ｓ４１）。このＡ
ＰＩは指定したメモリ領域ない対する書き込みが発生し
たか否かの検出を依頼するアプリケーションプログラム
インタフェースである。続いてオブジェクトをＦｒｏｍ
領域からＴｏ領域に複写する（ｓ４２）。その後、上記
ＡＰＩ＃Ｄを発行する（ｓ４３）。このＡＰＩは上記Ａ
ＰＩ＃Ｃが呼び出されてから、このＡＰＩ＃Ｄが呼び出
されるまでの間に指定メモリ領域に何らかのデータの書
き込みが発生したか否かが戻り値として返されるアプリ
ケーションプログラムインタフェースである。したがっ
て、複写しようとするオブジェクトのメモリ領域を指定
してＡＰＩ＃Ｃを発行し、ＡＰＩ＃Ｄも戻り値を見れ
ば、そのオブジェクトが参照されたか否かが判る。オブ
ジェクトが参照されていれば、内容が書き変わっている
可能性があるので、そのオブジェクトの複写をやり直す
（ｓ４４→ｓ４１→・・・）。

【００８７】図１４は上記ＡＰＩ＃ＣおよびＡＰＩ＃Ｄ
のカーネルにおける処理手順を示すフローチャートであ
る。ＡＰＩ＃Ｃの発行（システムコール）があれば、所
定にワークエリアをクリアし、ＡＰＩ＃Ｃのパラメータ
で指定された領域がライトされたときに例外が発生する
ようにＭＭＵ（Memory Management Unit) を設定する。
また、ＡＰＩ＃Ｄが発行されると、上記パラメータで指
定された領域がライトされたときに例外が発生しないよ
うに、ＭＭＵに対する上記設定を解除する。そして上記
ワーク領域にセットされるフラグの状態を戻り値として
スレッドに返す。

【００８８】図１５は上記例外発生時のＭＭＵの処理内
容を示すフローチャートである。例外が発生すると、上
記ワーク領域内の参照フラグをセットする。

【００８９】なお、上述の例では複写法によるＧＣの場
合について示したが、マーク＆スイープ法におけるコン
パクションの場合にも同様に適用できる。

【００９０】〔第２の実施形態〕図１６および図１７は
インクリメンタルにガベージコレクションできるＧＣス
レッドの優先度を自動的に切り替えるようにした場合の
例を示す図である。

【００９１】図１６の（Ａ）に示すように、ＧＣスレッ
ドの優先度を、高優先度時間は高め（例えば最高優先度
にし）、低優先度時間は低く（例えば最低優先度）する
動作を交互に行う。

【００９２】同図の（Ｂ）はＧＣスレッド以外の中程度
の優先度のスレッドを同時に行った場合の例について示
している。すなわちＧＣスレッドの優先度が低いとき、
それより優先度の高いスレッドがＲｅａｄｙ状態となれ
ば、コンテキストがスイッチされ、そのスレッドの実行
中にＧＣスレッドの優先度が高くなれば、そのＧＣスレ
ッドにコンテキストがスイッチされ、そのＧＣスレッド
の処理が中断すると、上記のＧＣスレッド以外のスレッ
ドの処理を行うことになる。このようにすれば、一定周
期で必ずＧＣスレッドが実行されるため、フリー領域が
慢性的に不足状態となることが防止され、常に高いパフ
ォーマンスを維持することができる。

【００９３】図１７はスレッドの優先度の切替に関する
カーネルの行う処理手順を示すフローチャートである。
優先度の値は複数段階あり、その値の設定は対応するＡ
ＰＩの発行により行えるようにしている。ここでは、Ｇ
Ｃスレッドの２つの優先度を設定する際、高優先度の値
を設定するＡＰＩが発行されると、図１７の（Ａ）に示
すように、その値をＧＣスレッドの高優先度の値として
設定する。同様に、低優先度の値を設定するＡＰＩが発
行されると、（Ｂ）に示すように、その値をＧＣスレッ
ドの低優先度の値として設定する。また、ＧＣスレッド
の高優先度の時間を設定するＡＰＩが発行されると、同
図の（Ｃ）に示すように、その値を設定し、同様に低優
先度の時間を設定するＡＰＩが発行されると、同図の
（Ｄ）に示すように、その値を設定する。

【００９４】図１７の（Ｅ）は、カーネルのスケジュー
ラに対する処理手順を示すフローチャートである。ここ
では、初期状態で、高優先度のキューにＧＣスレッドが
資源の割当を受けようとする待ち行列に入っているもの
とし、先ず、そのデータ（ＧＣスレッドを識別するデー
タ）を高優先度のキューから取り出して低優先度のキュ
ーに挿入する（ｓ５１）。そしてスケジューラは、既に
設定されている低優先度時間だけ時間待ちを行い（ｓ５
２）、続いて低優先度のキューからＧＣスレッドを識別
するデータを取り出して高優先度のキューに挿入する
（ｓ５３）。そしてスケジューラは、既に設定されてい
る高優先度時間だけ時間待ちを行う（ｓ５４）。以上の
処理を繰り返すことによって、スケジューラの動作によ
り図１６（Ａ）に示したようにＧＣスレッドの優先度が
交互に切り替わる。ＧＣスレッド以外のスレッドについ
ては、そのスレッドの優先度に対応するキューの待ち行
列に応じて従来と同様のスケジューリングが行われ、図
１６の（Ｂ）に示したように、コンテキストスイッチが
なされる。

【００９５】図１８は上記のＧＣスレッドの高優先度時
間をＡＰＩによって設定可能とした場合について示して
いる。また、図１９はそのＡＰＩの呼び出しに応じたカ
ーネルにおける処理手順を示すフローチャートである。
このＡＰＩの発行（システムコール）があれば、上記の
高優先度時間をそのＡＰＩのパラメータによって設定
（登録）する。

【００９６】図２０は上記のＧＣスレッドの高優先度時
間を設定可能とするＡＰＩを使うプログラムの例を示す
フローチャートである。先ず、ループの１回目の示すフ
ラグの状態を見る（ｓ６１）。最初はＯＦＦ状態である
ので、このフラグをＯＮし（ｓ６２）、現在のフリー領
域を調べ、それを記録する（ｓ６３）。初めはＧＣの高
優先度時間と低優先度時間は予め定められたデフォルト
値である。スケジューラにより、一定時間停止した後
（ｓ６４）、今度は、前回に調べたフリー領域の容量と
現在のフリー領域の容量との大小比較を行い（ｓ６
５）、フリー領域の容量が増加していれば、ＧＣスレッ
ドの高優先度時間を短くし（ｓ６６→ｓ６７）、フリー
領域の容量が減少していれば、ＧＣスレッドの高優先度
時間を長くする（ｓ６８）。以上の処理を繰り返す。こ
のことによって、ＧＣの優先度が動的に自動調整され
る。

【００９７】図２１はＧＣスレッドの高優先度時間と低
優先度時間とによる周期を設定可能とした場合について
示している。（Ａ）は周期が長い場合、（Ｂ）は短い場
合である。

【００９８】図２２は上記周期を設定可能とする周期設
定ＡＰＩの呼び出しに応じたカーネルにおける処理手順
を示すフローチャートである。この周期設定ＡＰＩの発
行があれば、現在設定されている高優先度時間および低
優先度時間の値を読み取り、その割合（比率）を計算す
る（ｓ７１→ｓ７２→ｓ７３）。その後、この周期設定
ＡＰＩのパラメータで指定された周期の値に応じて高・
低優先度時間を再計算する（ｓ７４）。そして、その高
優先度時間および低優先度時間を設定更新する（ｓ７５
→ｓ７６）。

【００９９】たとえば連続的なパルスを処理するよう
な、連続してＣＰＵ資源が必要なアプリケーションプロ
グラムの場合には、ＧＣスレッドの周期が短くなるよう
に周期設定ＡＰＩを発行し、通常のアプリケーションプ
ログラムのように断続的にＣＰＵ資源を利用するアプリ
ケーションプログラムでは周期が長くなるように周期設
定ＡＰＩを発行する。

【０１００】〔第３の実施形態〕図２３および図２４は
必要な時点でＧＣスレッドを実行し、且つリアルタイム
性を確保するようにした例であり、図２３に示す例で
は、スレッド１とスレッド３がリアルタイム性の要求さ
れるスレッド、スレッド２がリアルタイム性の要求され
ないスレッド（ノーマルスレッド）である。また、スレ
ッド３がＧＣスレッドである。メモリのフリー領域が多
い通常状態で、スレッド２が実行されているときにイベ
ント１が発生すれば処理がスレッド１に移され、イベン
ト１の処理に起因するスレッド１の処理が終了すればス
レッド２へ戻る。同様に、イベント２が発生すればスレ
ッド３に処理が移る。もしスレッド２の処理によってフ
リー領域が予め定めた警告レベルまで低下したとき、ス
レッド２の処理を中断して、スレッド３のＧＣスレッド
を実行する。この処理によってフリー領域が確保される
とスレッド２の処理へ戻る。もしＧＣスレッドの処理途
中でイベント１が発生すれば、ＧＣの途中であってもス
レッド１へ処理が移る。このようにリアルタイム性の要
求されるスレッドでは、一般に生成されるオブジェクト
の量が少なく、大体の予測が可能であるので、それに応
じて上記警告レベルを設定しておけば、スレッド２に処
理によって、フリー領域が大幅に減少してスレッド１や
スレッド３のリアルタイム性の要求される処理が実行で
きなくなるといった、不都合が回避できる。

【０１０１】図２４は上記コンテキストスイッチの処理
を行うスケジューラの処理手順を示すフローチャートで
ある。先ずイベントの発生有無を検知し（ｓ８１）、イ
ベントが発生していれば、対応するリアルタイムスレッ
ドにコンテキストをスイッチする（ｓ８２）。イベント
が発生していなくて、フリー領域が警告レベルより多け
れば、ノーマルスレッドのうち優先度の最も高いもの
（図２３に示した例ではスレッド２）にコンテキストを
スイッチする（ｓ８３→ｓ８４）。もしフリー領域が警
告レベルより少なくなれば、ＧＣスレッドにコンテキス
トをスイッチする（ｓ８５）。

【０１０２】〔第４の実施形態〕図２５はコンテキスト
スイッチの検出を依頼するＡＰＩにおける強制コンテキ
ストスイッチの例を示している。先に示した例では、Ａ
ＰＩ＃Ａを発行してから、ＡＰＩ＃Ｂを発行するまでの
間にコンテキストスイッチが発生したか否かが判るよう
にしたものであったが、この図２５に示す例は、ＧＣの
優先度を高・低交互に切り替える場合に、上記の排他制
御のためのＡＰＩを発行している間にコンテキストスイ
ッチが発生することを予測して、無駄な処理を行わない
ようにしたものである。すなわち、高優先度ＧＣスレッ
ドを実行中にＡＰＩ＃Ａ′を発行した際、ＡＰＩ＃Ａ′
は高優先度時間が終了するまでに、必要な処理が完了す
るか否かを判定して、もし完了しなければ、その時点で
ＧＣスレッドの優先度を低くする。図２５に示した例で
は、ＧＣスレッドの優先度が低くなったことにより、Ｇ
Ｃスレッド以外の中優先度のスレッドにコンテキストス
イッチされることになる。このことにより無駄な処理が
避けられる。

【０１０３】図２６は上記ＡＰＩ＃Ａ′の呼び出しに応
じたカーネルにおける処理手順を示すフローチャートで
ある。このＡＰＩの呼び出しがあれば、コンテキストス
イッチフラグをクリアし（ｓ９１）、ＧＣスレッドの高
優先度時間の残時間を取得する（ｓ９２）。そして、こ
のＡＰＩ＃Ａ′のパラメータである排他時間（ＡＰＩ＃
Ａ′を発行してから、ＡＰＩ＃Ｂを発行するまでの時
間）と上記残時間との大小比較を行う（ｓ９３）。も
し、残時間が排他時間より短ければＧＣスレッドの優先
度を強制的に低くする（ｓ９４）。なお、ＡＰＩ＃Ｂ呼
び出しによる処理内容とコンテキストスイッチの処理内
容は図８および図９に示したものと同様である。

【０１０４】〔第５の実施形態〕図２７はメモリ（ヒー
プ領域）使用量に応じてＧＣのアルゴリズムを切り替え
るための処理手順を示すフローチャートである。先ず、
メモリ使用量の値とそれに応じてどのアルゴリズムでＧ
Ｃを行うかを示すしきい値を設定し（ｓ１０１）、メモ
リ使用量を取得する（ｓ１０２）。これはヒープ領域内
に生成されたオブジェクトのメモリサイズの合計値であ
る。メモリ使用量がしきい値ｔｈ１を超えた場合、ＧＣ
アルゴリズム（１）の手順でＧＣを行う（ｓ１０３→ｓ
１０４）。メモリ使用量がしきい値ｔｈ２を超えたな
ら、ＧＣアルゴリズム（２）の手順でＧＣを行う（ｓ１
０５→ｓ１０６）。以下同様である。ここで、しきい値
ｔｈ１はしきい値ｔｈ２より小さく、ＧＣアルゴリズム
（１）としては図１６に示した、ＧＣスレッドの優先度
の高低を交互に繰り返す処理を行う。しきい値の高いと
きに行うＧＣアルゴリズムとしては、図２３に示した不
定期のＧＣを実行する。ここでＧＣ自体は例えばマーク
＆スイープ法により行う。通常、前者の場合にはＣＰＵ
負荷が軽く、専らこの方法によりＧＣが行われるが、ノ
ーマルスレッドによって短時間に大量のメモリが使用さ
れた場合には、図２３に示した方法によりＧＣを重点的
に行う。このことによって常に広いフリー領域を確保
し、且つリアルタイム性を維持する。

【０１０５】〔第６の実施形態〕図２８〜図３０はオブ
ジェクト生成時のヒープ領域に対する新たなオブジェク
トの割り当てサイズを定めるための処理に関する図であ
る。一般にプログラムの実行により生成されるオブジェ
クトのサイズの分布は図２８に示すように略正規分布を
示す。その中心値は３２と６４バイトの間に納まる程度
である。そこで、図２９の（Ａ）に示すように、この中
心値より大きなサイズで、且つ２の巾乗バイトの整数倍
のサイズをオブジェクトの割り当てサイズとする。従来
は同図の（Ｂ）に示すように、生成すべきオブジェクト
のサイズの量だけ任意に割り当てられていたため、その
オブジェクトの消去の際、不揃いのサイズのフラグメン
トが生じる。本願発明によれば、新たに生成されるオブ
ジェクトのサイズが上記固定値の整数倍であるため、メ
モリ領域の再利用性が高まり、メモリ使用効率が全体に
高まる。しかも場合によってはコンパクションが不要と
なる。

【０１０６】図３０はそのオブジェクト生成時の処理手
順を示すフローチャートである。先ず、これまでに生成
したオブジェクトのサイズの発生頻度の分布データを求
める（ｓ１１１）。既に前回までに分布データを求めて
いる場合には、それを更新する。続いて、今回割り当て
るべきメモリの空いている領域で、且つ生成しようとす
るオブジェクトのサイズより大きな領域を探し、上記の
固定サイズの整数倍のメモリ領域にオブジェクトを割り
当てる（ｓ１１２→ｓ１１３→ｓ１１４→ｓ１１５）。
上記２の巾乗バイトはシステム定数であるが、必ずしも
この値を固定サイズとする必要はなく、任意である。固
定サイズをもし大き過ぎる値に採れば、サイズの大きな
領域に小さなオブジェクトが割り当てられる場合が増え
ることになり、逆に、固定サイズを小さ過ぎる値に採れ
ば、オブジェクトの生成に再利用できない領域が増える
ことになる。分布データを基に上記固定サイズを決定す
る場合には、メモリの使用効率が最適となるように決定
すればよい。また、最適値でなくても、例えば２の巾乗
の値を採れば、アドレス決定がやり易くなるという効果
を奏する。

【０１０７】図３１は上記オブジェクトのサイズの発生
頻度分布データを求めるプログラムモジュール、および
オブジェクトの割り当てサイズを決定するプログラムモ
ジュールの処理内容を示すフローチャートである。先
ず、オブジェクトのサイズの発生頻度分布データを求め
るプログラムモジュールをロードし（ｓ１２１）、その
プログラムモジュールを起動する。すなわち一定時間が
経過するまで（たとえばアプリケーションプログラムの
起動・終了が１０回行われるまで、またたとえば２４時
間経過するまで）、生成された各オブジェクトのサイズ
をサイズ毎に計数し、その分布データを求める（ｓ１２
２→ｓ１２３）。その後、その分布データをシステムに
登録し（ｓ１２４）、オブジェクトのサイズの発生頻度
分布データを求めるプログラムモジュールをアンロード
する（ｓ１２５）。続いて固定サイズを決定するプログ
ラムモジュールをロードし（ｓ１２６）、そのプログラ
ムモジュールを実行する。すなわちシステムの登録され
た分布データを取得し、その分布中心値より大きなサイ
ズで、且つたとえば２の巾乗バイトを固定サイズとして
決定し、その値をシステムに登録する（ｓ１２７→ｓ１
２８）。その後、固定サイズを決定するプログラムモジ
ュールをアンロードする（ｓ１２９）。

【０１０８】このように、一度オブジェクトのサイズの
分布が検知された後、および固定サイズが決定された後
は、それらのためのプログラムモジュールをアンロード
することによって、メモリ領域とＣＰＵパワーの無駄を
無くす。

【０１０９】〔第７の実施形態〕図４９は上記固定サイ
ズをＡＰＩによって設定する例を示している。図に示す
ように、固定サイズ設定処理では、固定サイズを引数と
して固定サイズ設定ＡＰＩを呼び出す。呼び出されたＡ
ＰＩでは、引数を固定サイズとしてシステムに登録す
る。オブジェクト生成時にはオブジェクトのサイズと固
定サイズを比較し（ｓ２１１）、固定サイズ以下であれ
ば、ヒープ上の固定サイズの空き領域を探し、見つかっ
た領域をオブジェクトに割り当てる（ｓ２１２→ｓ２１
３）。固定サイズを超える場合は、ヒープ上のオブジェ
クトサイズより大きな空き領域を探し、見つかった領域
をオブジェクトに割り当てる（ｓ２１４→ｓ２１５）。

【０１１０】〔第８の実施形態〕図５０は上記固定サイ
ズをＡＰＩによって設定する他の例を示している。図５
０に示すように、この例では、まずオブジェクトサイズ
の分布データをオブジェクトサイズ分布設定ＡＰＩを呼
び出して設定する。この分布データは予め所定時間所定
のアプリケーションを実行して測定したものである。オ
ブジェクトサイズ分布設定ＡＰＩは呼び出しに応答し
て、引数をオブジェクトサイズ配列変数にセットする。
続いて、その中心値より大きなサイズで、且つ２の巾乗
バイトを固定サイズとして決定し、これを固定サイズ変
数にセットする。

【０１１１】〔第９の実施形態〕図５１〜図５３はオブ
ジェクトの割り当てサイズを予めいくつかのサイズに定
めておく例を示す図である。図５１は事前に所定のアプ
リケーションを所定時間実行して測定したオブジェクト
サイズの分布および分割領域の集合を表している。予め
ヒープ領域を分割する場合、実際のオブジェクトサイズ
の分布を測定し、その分布に近くなるように、分割サイ
ズと数を定める。たとえば、ヒープ領域が２ＭＢの場
合、分割サイズ指定変数を集合No.n バイトk 個数m 1 64 5000 2 256 10000 3 1k 10000 4 4k 5000 5 32k 500 とする。

【０１１２】上記分割サイズを設定する場合、図５２に
示すように、分割サイズ設定ＡＰＩを呼び出して行う。
呼び出された分割サイズ設定ＡＰＩは図５３に示すよう
に、引数を分割サイズ指定変数にセットし、それに応じ
てヒープ領域を分割する。すなわち、まずループカウン
タｎを０とし（ｓ２２１）、ｎ番目の分割サイズ指定変
数からサイズｋと個数ｍを取得する（ｓ２２２）。続い
てヒープ領域からサイズｋの領域をｍ個に分割し（ｍ個
分確保し）、リストに登録する（ｓ２２３）。この処理
をループカウンタｎを１インクリメントしながら繰り返
し、全てのサイズの分割を行う（ｓ２２５→ｓ２２２→
・・・）。なお、上記の例で、サイズが３２ｋバイトを
超えるオブジェクトを生成する場合は、ヒープ領域内の
上記分割された領域以外の領域に割り当てる。

【０１１３】〔第１０の実施形態〕図３２〜図３４はオ
ブジェクトの寿命を考慮してＧＣの効率を高めるための
処理を行う例を示す図である。図３２の（Ａ）に示す例
では、ヒープ領域として、短寿命のオブジェクトを生成
する領域と長寿命のオブジェクトを生成する領域とに分
け、クラスは長寿命領域に確保する。尚、クラスはその
他の固定領域に確保してもよい。そして、クラスにはオ
ブジェクトを生成するためのテンプレートとしての定義
情報以外に、生成するオブジェクトの寿命を示す寿命フ
ラグを持たせる。この寿命フラグはクラスの生成時に自
動的に生成する。同図の（Ｂ）は従来のヒープ領域に対
するオブジェクトの割り当て例を示す図である。

【０１１４】図３３はオブジェクトの消去の手順を示す
フローチャートである。同図に示すようにオブジェクト
を消去した際に、そのオブジェクトの寿命が長いか短い
かを判定し、寿命が短ければ、そのオブジェクトのクラ
スの寿命フラグを短寿命にセットする。例えばオブジェ
クトの領域内にそのオブジェクトが生成された時刻を格
納しておき、そのオブジェクトを消去する時刻との差に
よって、そのオブジェクトの寿命を求める。上記時刻は
例えばＧＣの回数を単位としてもよい。

【０１１５】図３４はオブジェクトの生成の処理手順を
示すフローチャートである。クラスの寿命フラグが短寿
命を示していれば、短寿命領域にオブジェクトを生成
し、そうでなけば、長寿命領域にオブジェクトを生成す
る。

【０１１６】このようにオブジェクトの寿命に応じてメ
モリの割り当て領域を区分することによって、長寿命領
域ではフラグメントを大幅に低下でき、メモリの使用効
率が向上する。また、例えば寿命領域についてＧＣを重
点的に行うことにより、ＧＣに消費されるＣＰＵパワー
を小さくすることができる。

【０１１７】〔第１１の実施形態〕次に、マーク＆スイ
ープ法によるインクリメンタルＧＣについて図３５〜４
８を参照して説明する。

【０１１８】図３５はマーク＆スイープ法によるＧＣの
全体の処理手順を示すフローチャートである。このＧＣ
はマークテーブルのクリア、上記ツリー探索によるマー
ク付与およびオブジェクトの消去（スイープ）を繰り返
し行う。

【０１１９】図３６は図３５における「マーククリア」
の処理内容を示すフローチャートである。この処理はマ
ークテーブルの内容を一旦クリアするものであり、まず
マークテーブルの先頭にポインタを移動し（ｓ１３
１）、その位置のマークをクリアし（ｓ１３２）、次の
マークの位置までポインタを移動させる（ｓ１３３）。
この処理を全てのマークについて繰り返す（ｓ１３４→
ｓ１３２→・・・）。

【０１２０】図３７は図３５における「オブジェクトの
消去」の処理内容を示すフローチャートである。先ず、
マークテーブルの先頭にポインタを移動させ（ｓ１４
１）、マークの有無を検出し、マークされていなけれ
ば、そのマークテーブル上の位置に相当するオブジェク
トのヒープ領域内の位置を計算し、該当のオブジェクト
を消去する（ｓ１４２→ｓ１４３→ｓ１４４）。続い
て、マークテーブルのポインタを次に移動して、同様の
処理を繰り返す（ｓ１４５→ｓ１４６→ｓ１４２→・・
・）。これによりマークテーブルにマークされているオ
ブジェクトを残し、その他のオブジェクトをヒープ領域
から消去する。

【０１２１】説明を容易にするために、先ず前提となる
マーク＆スイープ法におけるマーク付与について説明す
る。

【０１２２】図３８はツリー探索によるマーク付与の手
順を示す図である。（Ａ）に示すように、ルートノード
１０から各ノードへ、ツリー構造で表される参照関係を
辿って、参照関係にあるノード（オブジェクト）にマー
クを付与する。具体的にはマークテーブル上の該当位置
のビットをセットする。このツリー構造は、たとえば或
るオブジェクトが他のどのオブジェクトを参照している
かを示す、オブジェクト内に設けられる変数の内容によ
って構成され、このオブジェクトの参照関係を辿ること
が、すなわちツリーを辿ることである。

【０１２３】（Ａ）のように、ノード番号３までマーク
付与を行った時点で割込が発生し、その割込処理によっ
て、（Ｂ）のように、ルートノードからノード番号７で
表されるオブジェクトへの参照関係が絶たれて、ノード
番号２で表されるオブジェクトからノード番号７で表さ
れるオブジェクトが参照される関係となれば、割込処理
が終了してＧＣスレッドに戻って、マーク付与を再開し
たとき、ルートノードからノード番号７で表されるオブ
ジェクトへの参照関係が絶たれているので、（Ｃ）に示
すようにポインタをルートノードに戻して次の参照関係
にあるノード番号８に進むことになる。この時点ではノ
ード番号５，６に対してはマーク付与されない。そこ
で、参照関係の変更のあったオブジェクトについては、
そのオブジェクトからツリーを辿ってそのオブジェクト
から参照されているオブジェクトについてマークを付与
する必要がある。

【０１２４】図３９は「オブジェクトの生成」の処理内
容を示すフローチャートである。まずカーネルに対して
システムのロックを起動し（ｓ１５１）、ヒープ領域内
の空いている領域を探し（ｓ１５２）、生成しようとす
るオブジェクトのサイズより大きな領域に対して必要な
サイズを割り当て（ｓ１５３→ｓ１５４）、参照変更の
マーク付与（ライトバリア）を行い（ｓ１５５）、シス
テムをアンロックする（ｓ１５６）。

【０１２５】図４０は上記「参照変更のマーク付与」の
処理手順を示すフローチャートである。先ず、参照変更
されたオブジェクトからマークテーブル上の位置を計算
し、該当のマークがWhite であるか否かを判定する。こ
のWhite マークはたとえば00の２ビットで表され、未だ
マークされていない状態を意味する。もし、White マー
クでなければ、すでにマークされているので、そのまま
処理を終了する。White マークであれば、それをGrayに
マークする。このGrayマークはたとえば01の２ビットで
表され、参照変更のあったオブジェクトであることを意
味する。なお、オブジェクトからマークの位置を計算す
る際、たとえばオブジェクトのアドレスを１／８してオ
フセットを加えることによって行うか、オブジェクトの
通し番号により計算する。

【０１２６】図４１は「ツリー探索によるマーク付与」
の処理手順を示すフローチャートである。まず、ツリー
を辿るためのポインタをツリーのルートノードに移動さ
せ（ｓ１６１）、新たに生成するオブジェクトに対応す
るマークを付与する（ｓ１６２）。続いてツリーを辿っ
て、ポインタを次のオブジェクトへ移動させ（ｓ１６
３）、この処理をツリーの最後まで繰り返す（ｓ１６４
→ｓ１６２→・・・）。その後、各スレッドスタックの
先頭へポインタを移動させ（ｓ１６５）、スタックにあ
るオブジェクトに対応するマークを付与する（ｓ１６
６）。その後、ポインタをスタックの次に移動させて
（ｓ１６７）、この処理をツリーの最後まで繰り返す
（ｓ１６８→ｓ１６６→・・・）。その後、スレッドス
タックの次に移り（ｓ１６９）、同様の処理をスレッド
スタックの最後まで繰り返す（ｓ１７０→ｓ１６６→・
・・）。さらにこのスレッドスタックについての処理を
すべてのスレッドスタックについて行う（ｓ１７１→ｓ
１７２→ｓ１６５→・・・）。この一連のツリー探索に
おいて、Grayマークが途中で１度でも検出された場合、
もう一度ルートノードから探索およびマーク付与を行う
（ｓ１７３→ｓ１６１→・・・）。

【０１２７】図４２は図４１における「オブジェクトに
対応するマーク付与」の処理手順を示すフローチャート
である。この処理は、生成されているオブジェクトから
マークテーブル上の位置を計算し、Black マークを付与
する。このBlack マークはたとえば1xの２ビットで表さ
れ、マークされている状態を意味する。

【０１２８】上述したようなマーク付与の方法では、そ
の途中で割込がかかってオブジェクトの参照関係が変化
すると、Grayマークが付与されるので、ツリー探索を繰
り返さなければならない。場合によってはいつまでたっ
てもマーク付与が完了せずに、ＧＣがいつまでも行われ
ないといった事態に陥る。

【０１２９】図４３は上記の問題を解消するための「ツ
リー探索によるマーク付与」の手順を示す図である。
（Ａ）は図３８に示した（Ａ）の状態で割込がかかって
参照関係が変化したときの状態を示す。このように、ノ
ード番号３までマーク付与を行った時点で割込が発生
し、その割込処理によって、ルートノードからノード番
号７で表されるオブジェクトへの参照関係が絶たれて、
ノード番号２で表されるオブジェクトからノード番号７
で表されるオブジェクトが参照される関係となれば、参
照先のノード番号７表すデータをマークスタックに積
む。その後、割込処理が終了してＧＣスレッドに戻っ
て、マーク付与を再開したとき、ルートノードからノー
ド番号７で表されるオブジェクトへの参照関係が絶たれ
ているので、（Ｂ）に示すようにポインタをルートノー
ドに戻して次の参照関係にあるノード番号８をマークす
る。この時点で一通りのツリー探索を終了し、その後
は、（Ｃ）に示すようにマークスタックの内容によって
示されるノードからツリーを辿って参照関係にあるオブ
ジェクトについてマークを付与する。これにより（Ｄ）
に示すように、参照関係にある全てのオブジェクトにつ
いてのマーク付与が完了する。

【０１３０】図４４は「参照変更のマーク付与」の処理
手順を示すフローチャートである。このように、参照変
更されたオブジェクトを示すデータを上記マークスタッ
クに積む。なお、オブジェクトの生成の処理は図３９に
示したもの変わらない。

【０１３１】図４５は、「ツリー探索によるマーク付
与」の処理手順を示すフローチャートである。ステップ
ｓ１６１〜ｓ１７２の部分は図４１に示したフローチャ
ートのステップｓ１６１〜ｓ１７２と同じである。この
図４５に示す例では、全スレッドスタックについてのツ
リー探索を完了した後、マークスタックからデータを取
り出し（ｓ１８１→ｓ１８２）、そのデータで示される
オブジェクトに対応するマーク付与を行い（ｓ１８
３）、そのオブジェクトからツリーを辿ってツリーの最
後まで、参照関係にあるオブジェクトのマーク付与を行
う（ｓ１８４→ｓ１８５→ｓ１８３→・・・）。この処
理をマークスタックが空になるまでマークスタックのポ
インタを更新しながら繰り返す（ｓ１８１→ｓ１８２→
・・・）。

【０１３２】図４６は図４５における「オブジェクトに
対応するマーク付与」の処理手順を示すフローチャート
である。この処理は、生成されているオブジェクトから
マークテーブル上の位置を計算し、マークを付与する。

【０１３３】このようにマークスタックを用いることに
よって、ツリー探索をルートノードから再開する必要が
なくなり、マーク付与に要する全体の処理時間を大幅に
短縮化できる。

【０１３４】図４７および図４８は上記マークスタック
を用いてマーク付与を行う場合に、更に無駄な処理時間
を無くすようするフローチャートである。図４７は上記
「参照変更のマーク付与」の処理手順を示すフローチャ
ートである。先ず、参照変更されたオブジェクトからマ
ークテーブル上の位置を計算し、該当のマークがWhite
であるか否かを判定する（ｓ１９１→ｓ１９２）。この
White マークは上述したように未だマークされていない
状態を意味する。もし、White マークでなければ、すで
にマークされているので、そのまま処理を終了する。Wh
ite マークであれば、それをGrayにマークする（ｓ１９
３）。上述したようにこのGrayマークは参照変更のあっ
たオブジェクトであることを意味する。続いてマークス
タックに参照先のオブジェクトを示すデータを積む（ｓ
１９４）。

【０１３５】図４８は上記「オブジェクトに対応するマ
ーク付与」の処理手順を示すフローチャートである。こ
の処理は、生成されているオブジェクトからマークテー
ブル上の位置を計算し、Black マークを付与する。この
Black マークは上述したように、マークされている状態
を意味する。なお、「オブジェクトの生成」の処理は図
３９に示したものと同様である。

【０１３６】このように、参照変更のあったオブジェク
トについてマークを付与する場合、そのオブジェクトが
初めて検出されたオブジェクトである場合にのみマーク
を付与するようにしたため、マークスタックの内容によ
るツリー探索に要する時間およびマークスタックの読み
出しに要する時間を短縮化できる。

【０１３７】なお、参照変更のあったオブジェクトにつ
いてのマークを記憶するのはスタックでなくてもよく、
ＦＩＦＯのバッファを用いてもよい。

【０１３８】また、実施形態ではマークテーブルにマー
クを付与するようにしたが、オブジェクトの内部にマー
ク用の情報を設けて、オブジェクトに直接マークを付与
するようにしてもよい。

【０１３９】

【発明の効果】請求項１，１８，２５に係る発明によれ
ば、コンピュータ資源をロックのメカニズムとして使用
せずに、処理の排他性が保証される。すなわち指定メモ
リ領域に対するデータの書き込み有無検出の開始を依頼
するＡＰＩの呼び出しから指定メモリ領域に対するデー
タの書き込み有無検出の終了を依頼するＡＰＩの呼び出
しまでの間で行われたスレッドＡの処理の途中で、他の
スレッドによる指定メモリ領域に対する書き込みがあっ
たか否かが、そのスレッドＡで分かる。書き込みが行わ
れていなければ、指定メモリ領域の排他性が保たれてい
る。もし書き込みが行われていれば、スレッドＡのその
間の処理を無効にして、例えばその処理を再度実行する
などの方法によって高い応答性を保ちながら、排他制御
を行うことができるようになる。

【０１４０】請求項２，１９，２６に係る発明によれ
ば、ＧＣスレッドの優先度を交互に切り替えることによ
って、ＧＣスレッドの優先度が低い状態では、他のスレ
ッドによるアプリケーションが優先され、動作するアプ
リケーションが無い場合にはＧＣスレッドが自動的に動
かされ、メモリのフリー領域が自動的に拡大される。Ｇ
Ｃスレッドの優先度が高い状態では、他のスレッドは実
行されないが、優先度の低い状態で、他のスレッドによ
り、ＧＣが継続して行われないことによってフリー領域
が慢性的に不足状態となることが防止され、常に高いパ
フォーマンスを維持することができる。

【０１４１】請求項３に係る発明によれば、ＡＰＩを呼
び出す側で、たとえばシステムの応答性を重視する場合
には優先度の高い状態の時間を短くし、システム全体の
スループットを重視する場合には優先度の高い状態の時
間を長くする、といった設定が可能となり、システムの
ニーズに応じて性能を変えることができるようになる。

【０１４２】請求項４に係る発明によれば、たとえば連
続的なパルスを処理するような、連続してＣＰＵ資源が
必要なアプリケーションプログラムの場合には、周期を
短くし、通常のアプリケーションプログラムのような断
続的にＣＰＵ資源を利用するアプリケーションプログラ
ムでは周期を長くすることによって、コンテキストスイ
ッチなどのオーバヘッドを小さくすることができる。

【０１４３】請求項５に係る発明によれば、動的にガベ
ージコレクションの優先度の高い状態の時間を調整する
ことになり、どのようなアプリケーションプログラムで
もフリー領域が足りなくなるといった状況を回避するこ
とができ、且つフリー領域が十分確保できるシステムや
アプリケーションプログラムでは、ガベージコレクショ
ンを最低限に抑えることができる。

【０１４４】請求項６，２０，２７に係る発明によれ
ば、リアルタイム性の要求されないスレッドがオブジェ
クトを生成して、メモリのフリー領域の量が例えばリア
ルタイム性の要求されるスレッドが生成するオブジェク
トの量の近傍にまで減少した時に、その時点でスケジュ
ーリングが行われ、ＧＣスレッドが実行されるため、フ
リー領域が直ちに確保され、リアルタイム性の要求され
るスレッドの実行可能な環境を常に維持することができ
る。

【０１４５】請求項７，２１，２８に係る発明によれ
ば、フリー領域または使用領域の量に応じてＧＣの手順
を切り替えることによって、常に効率的なＧＣが可能と
なる。

【０１４６】請求項８，２２，２９に係る発明によれ
ば、多くのオブジェクトが先に使用されていたメモリ領
域を再利用できることになり、このことにより、コンパ
クションを行わなくてもメモリの使用効率が向上するこ
とになる。また、コンパクションのためのＣＰＵパワー
が不要となり、小規模のＣＰＵで応答性の高いシステム
を構成することができる。

【０１４７】請求項９，１０に係る発明によれば、一度
オブジェクトのサイズの分布が検知された後は、また、
オブジェクトの割り当てサイズが決定された後は、メモ
リ領域とＣＰＵパワーの無駄がなくなる。

【０１４８】請求項１１，１２，３０に係る発明によれ
ば、多くのオブジェクトがメモリのヒープ領域を無駄な
く再利用できることになり、コンパクションを行わなく
てもメモリの使用効率が向上する。また、コンパクショ
ンのためのＣＰＵパワーが不要となり、小規模のＣＰＵ
で応答性の高いシステムを構成することができる。

【０１４９】請求項１３，１４，３１，３２に係る発明
によれば、別の装置、システム、およびアルゴリズム
で、メモリのヒープ領域内に割り当てられるオブジェク
トのサイズの分布を測定して、決定したオブジェクトの
割り当てサイズの基になる固定サイズを登録することが
でき、ＣＰＵパワーとメモリの使用効率を向上させるこ
とができる。

【０１５０】請求項１５，２３，３３に係る発明によれ
ば、寿命データに基づいて、異なったヒープ領域にオブ
ジェクトを生成することによって、長寿命のオブジェク
トと短寿命のオブジェクトが異なった領域に生成される
ため、長寿命領域でのフラグメントが大幅に低下し、メ
モリの使用効率が向上する。また、ＧＣを行う場合に、
短寿命のオブジェクトが生成される領域を重点的に処理
することによって、ＧＣに消費されるＣＰＵパワーを低
減することができるようになる。

【０１５１】請求項１６，２４，３４に係る発明によれ
ば、スイープやマークテーブルのクリアを行うときに、
他のスレッドを止めなくても、スイープ中またはマーク
テーブルのクリア中に他のスレッドにより新たなオブジ
ェクトが生成されたり、オブジェクト間の参照関係が変
更されても、マークテーブルを基にスイープを行う際
に、上記の新たに生成されたオブジェクトを消去してし
まうことがない。そのため、インクリメンタルにＧＣを
行うことができ、また、自由に中断ができるので、リア
ルタイム性が向上する。また、常にバックグラウンドで
ＧＣスレッドを動作させておくことが可能となり、メモ
リの使用効率を常に高く維持できる。しかも、ツリー探
索によるマーク付与に要する時間が短縮化され、割込に
よって、いつまでもマーク付与が完了しない、といった
不都合が防止でき、ＧＣを確実に実行できる。

【０１５２】請求項１７に係る発明によれば、オブジェ
クトの参照関係の変更時の参照先が既にマークされてい
る場合に、第２のデータを重ねて記憶することがなくな
り、第１のデータの探索およびマークに要する時間をそ
の分短縮化できる。

【図面の簡単な説明】

【図１】実施形態に係る装置のハードウエアの構成を示
すブロック図

【図２】同装置のソフトウエアの構成を示すブロック図

【図３】オブジェクト間の参照関係を示すツリーおよび
各スレッドのスタックとの関係を示す図

【図４】ソフトウエアの機能ブロック図

【図５】コンパクションの作用を説明するための図

【図６】コンテキストスイッチの有無によるスレッドの
処理内容の変化の例を示す図

【図７】排他制御の処理手順を示すフローチャート

【図８】コンテキストスイッチ発生有無検出のＡＰＩに
関する処理手順を示すフローチャート

【図９】コンテキストスイッチの処理手順を示すフロー
チャート

【図１０】コンパクションの処理手順を示すフローチャ
ート

【図１１】複写法によるＧＣの処理手順を示すフローチ
ャート

【図１２】複写法ＧＣにおける排他制御の処理手順を示
すフローチャート

【図１３】複写法ＧＣにおける他の排他制御の処理手順
を示すフローチャート

【図１４】図１３における排他制御用ＡＰＩに関する処
理手順を示すフローチャート

【図１５】図１３における排他制御用ＡＰＩに関する処
理手順を示すフローチャート

【図１６】ＧＣスレッドの優先度の自動切替の例を示す
図

【図１７】スレッドの優先度値および優先度時間の切替
に関するフローチャート

【図１８】ＧＣスレッドの高優先度時間を変更した例を
示す図

【図１９】ＧＣスレッドの高優先度時間を変更可能とす
るためのフローチャート

【図２０】ＧＣスレッドの高優先度時間を自動変更する
例を示すフローチャート

【図２１】ＧＣスレッドの高・低優先度時間の切り替え
周期を変更した例を示す図

【図２２】ＧＣスレッドの高・低優先度時間の切り替え
周期を変更するためのフローチャート

【図２３】不定期なＧＣ処理の例を示す図

【図２４】図２１に対応するフローチャート

【図２５】排他制御ＡＰＩによるＧＣスレッドの優先度
の強制変更の例を示す図

【図２６】排他制御ＡＰＩによるＧＣスレッドの優先度
を強制変更するためのフローチャート

【図２７】ＧＣのアルゴリズムを切り替える処理手順を
示すフローチャート

【図２８】生成されるオブジェクトのサイズの分布の例
を示す図

【図２９】オブジェクトのメモリの割り当てサイズの例
を示す図

【図３０】オブジェクト生成の処理手順を示すフローチ
ャート

【図３１】オブジェクトサイズの分布検知および固定サ
イズの決定処理に関するフローチャート

【図３２】ヒープ領域の構成を示す図

【図３３】オブジェクト消去の手順を示すフローチャー
ト

【図３４】オブジェクト生成の手順を示すフローチャー
ト

【図３５】マーク＆スイープ法によるＧＣの手順を示す
フローチャート

【図３６】マーククリアの処理手順を示すフローチャー
ト

【図３７】オブジェクト消去の処理手順を示すフローチ
ャート

【図３８】ツリー探索によるマーク付与の例を示す図

【図３９】図３８に対応するフローチャート

【図４０】図３８に対応するフローチャート

【図４１】図３８に対応するフローチャート

【図４２】図３８に対応するフローチャート

【図４３】ツリー探索によるマーク付与の例を示す図

【図４４】図４３に対応するフローチャート

【図４５】図４３に対応するフローチャート

【図４６】図４３に対応するフローチャート

【図４７】参照変更のマーク付与の他の処理手順を示す
フローチャート

【図４８】オブジェクトに対応するマーク付与の他の処
理手順を示すフローチャート

【図４９】固定サイズの設定とオブジェクト生成に関す
る処理手順を示すフローチャート

【図５０】オブジェクトサイズ分布設定に関する処理手
順を示すフローチャート

【図５１】オブジェクトサイズの分布と分割サイズの例
を示す図

【図５２】ヒープ領域を所定サイズで分割する処理とオ
ブジェクト生成に関する処理手順を示すフローチャート

【図５３】ヒープ領域を所定サイズで分割する処理に関
する処理手順を示すフローチャート

【図５４】従来のマーク＆スイープ法によるＧＣの手順
を示すフローチャート

───────────────────────────────────────────────────── フロントページの続き (72)発明者小中義治京都府京都市右京区花園土堂町10番地オムロン株式会社内 (72)発明者栗林博京都府京都市右京区花園土堂町10番地オムロン株式会社内

Claims

【特許請求の範囲】

【請求項１】或るスレッドからの、指定メモリ領域に
対するデータの書き込み有無検出の開始を依頼するアプ
リケーションプログラムインタフェースの呼び出しに応
答して、その書き込み有無を示すフラグを書き込み無し
の状態に設定する手段と、前記指定メモリ領域に対するデータの書き込みがあった
とき、前記フラグを書き込み有りの状態に設定する手段
と、前記スレッドからの、指定メモリ領域に対するデー
タの書き込み有無検出の終了を依頼するアプリケーショ
ンプログラムインタフェースの呼び出しに応答して、前
記フラグの状態に応じた値を前記スレッドに返す手段と
を備えたことを特徴とするプログラム制御装置。
【請求項２】メモリのヒープ領域内の、どのオブジェ
クトからも参照されないオブジェクトを検出し、当該オ
ブジェクトのメモリ領域を他のオブジェクトのメモリ割
り当て可能なフリー領域として解放するガベージコレク
ションスレッドをインクリメンタルに行う手段と、スレ
ッドの優先度に応じて各スレッドを時分割に実行するた
めのスケジューリングを行う手段と、前記ガベージコレ
クションスレッドの優先度をガベージコレクションスレ
ッド以外のスレッドの優先度より高い状態と低い状態と
に交互に変更する手段とを設けたことを特徴とするプロ
グラム制御装置。
【請求項３】前記ガベージコレクションスレッドの優
先度の高い状態の時間をアプリケーションプログラムイ
ンタフェースの呼び出しによって設定する手段を設けた
ことを特徴とする請求項２に記載のプログラム制御装
置。
【請求項４】前記ガベージコレクションスレッドの優
先度の高い状態と低い状態による周期をアプリケーショ
ンプログラムインタフェースの呼び出しによって設定す
る手段を設けたことを特徴とする請求項２に記載のプロ
グラム制御装置。
【請求項５】前記フリー領域の容量の時間変化を検出
する手段と、前記フリー領域の容量が低下傾向のとき、
前記ガベージコレクションスレッドの優先度の高い状態
の時間を長くする手段を設けたことを特徴とする請求項
２または３に記載のプログラム制御装置。
【請求項６】イベントの発生に応じてリアルタイムス
レッドを実行させ、該リアルタイムスレッドの中断時ま
たは終了時に非リアルタイムスレッドを実行させる手段
を備えたプログラム制御装置において、前記非リアルタイムスレッドの１つは、メモリのヒープ
領域内の、どのオブジェクトからも参照されないオブジ
ェクトを検出し、当該オブジェクトのメモリ領域を他の
オブジェクトのメモリ割り当て可能なフリー領域として
解放するガベージコレクションをインクリメンタルに行
うガベージコレクションスレッドであり、当該ガベージ
コレクションスレッド以外の非リアルタイムスレッドの
実行によりヒープ領域内の前記フリー領域が所定の値ま
で減少したとき、前記ガベージコレクションスレッドを
実行する手段を設けたことを特徴とするプログラム制御
装置。
【請求項７】メモリのヒープ領域内の、どのオブジェ
クトからも参照されないオブジェクトを検出し、当該オ
ブジェクトのメモリ領域を他のオブジェクトのメモリ割
り当て可能なフリー領域として解放する、手順の異なる
複数通りのガベージコレクションスレッドを選択的に実
行する手段と、前記フリー領域または前記オブジェクト
の使用領域の量に基づいて、前記複数通りの手順のうち
１つの手順のガベージコレクションスレッドを実行する
手段を設けたことを特徴とするプログラム制御装置。
【請求項８】メモリのヒープ領域内に割り当てられる
オブジェクトのサイズの分布を検知する手段と、前記分
布の中心より大きな固定サイズの整数倍を前記ヒープ領
域に対する新たなオブジェクトの割り当てサイズに決定
する手段とを設けたことを特徴とするメモリの割り当て
装置。
【請求項９】前記オブジェクトのサイズの分布を検知
する手段は、システムの使用開始時にシステムに組み込
まれ、前記オブジェクトのサイズの分布を検知した後に
システムから切り離されるプログラムモジュールによる
ものである請求項８に記載のメモリの割り当て装置。
【請求項１０】前記固定サイズを決定する手段は、シ
ステムの使用開始時にシステムに組み込まれ、前記固定
サイズが決定された後にシステムから切り離されるプロ
グラムモジュールによるものである請求項８に記載のメ
モリの割り当て装置。
【請求項１１】前記ヒープ領域内を予め複数のサイズ
に分割するヒープ領域分割手段と、オブジェクト生成時
に当該オブジェクトのサイズより大きく且つ最も小さな
サイズの領域を割り当てる手段を設けたことを特徴とす
る請求項８に記載のメモリの割り当て装置。
【請求項１２】前記ヒープ領域分割手段は、前記複数
のサイズの分割数と各サイズを引数とするアプリケーシ
ョンプログラムインタフェースの呼び出しによって、前
記ヒープ領域を分割するものである請求項１１に記載の
メモリの割り当て装置。
【請求項１３】メモリのヒープ領域内にオブジェクト
を生成する手段を備えたプログラム制御装置において、固定サイズの整数倍を前記ヒープ領域内に対するオブジ
ェクトの割り当てサイズに決定する手段と、アプリケー
ションプログラムインタフェースの呼び出しによって前
記固定サイズを設定する手段とを設けたことを特徴とす
るメモリの割り当て装置。
【請求項１４】メモリのヒープ領域内にオブジェクト
を生成する手段を備えたプログラム制御装置において、固定サイズの整数倍を前記ヒープ領域内に対するオブジ
ェクトの割り当てサイズに決定する手段と、前記ヒープ領域内に割り当てられるオブジェクトのサイ
ズの分布をアプリケーションプログラムインタフェース
の呼び出しによって設定する手段と、該アプリケーショ
ンプログラムインタフェースの呼び出しに応答して、前
記分布の中心より大きな値を前記固定サイズとして設定
する手段とを設けたことを特徴とするメモリの割り当て
装置。
【請求項１５】テンプレートとしてのクラスと該クラ
スにより生成されるオブジェクトをメモリのヒープ領域
内に割り当てるメモリの割り当て装置において、前記クラスからオブジェクトが生成された時刻に相当す
るデータを記憶し、前記オブジェクトを削除する際に、
当該オブジェクトの寿命を検出し、該寿命のデータをク
ラスに設け、当該クラスからオブジェクトを生成する際
に、前記寿命のデータに基づいて、前記ヒープ領域に対
するオブジェクトの生成領域を分ける手段を設けたこと
を特徴とするメモリの割り当て装置。
【請求項１６】メモリのヒープ領域内の、他のオブジ
ェクトから参照されるオブジェクトを検出して当該参照
の有無状態を記憶する参照情報記憶手段と、当該参照情
報記憶手段の記憶内容を基に、どのオブジェクトからも
参照されないオブジェクトのメモリ領域を他のオブジェ
クトのメモリ割り当て可能な領域として解放するオブジ
ェクト消去手段を設けたメモリ割り当て装置において、前記参照情報記憶手段は、オブジェクトの参照関係を表
すツリー構造の第１のデータと、オブジェクトの参照関
係の変更された部分のオブジェクトを示す第２のデータ
とを記憶し、第１のデータを探索して参照されているオ
ブジェクトを検出し、第２のデータを読み出すとともに
該データを基に第１のデータを探索して、参照されてい
るオブジェクトを検出する、参照オブジェクト検出手段
を設けたことを特徴とするメモリの割り当て装置。
【請求項１７】前記参照オブジェクト検出手段は、前
記オブジェクトの参照関係の変更時の参照先が前記第１
のデータの探索により初めて検出されたオブジェクトで
あるときにのみ、参照先の当該オブジェクトを前記第２
のデータとして記憶するものである請求項１６に記載の
メモリの割り当て装置。
【請求項１８】或るスレッドからの、指定メモリ領域
に対するデータの書き込み有無検出の開始を依頼するア
プリケーションプログラムインタフェースの呼び出しに
応答して、その書き込み有無を示すフラグを書き込み無
しの状態に設定するステップと、前記指定メモリ領域に対するデータの書き込みがあった
とき、前記フラグを書き込み有りの状態に設定するステ
ップと、前記スレッドからの、指定メモリ領域に対する
データの書き込み有無検出の終了を依頼するアプリケー
ションプログラムインタフェースの呼び出しに応答し
て、前記フラグの状態に応じた値を前記スレッドに返す
ステップとから成るプログラム制御方法。
【請求項１９】メモリのヒープ領域内の、どのオブジ
ェクトからも参照されないオブジェクトを検出し、当該
オブジェクトのメモリ領域を他のオブジェクトのメモリ
割り当て可能なフリー領域として解放するガベージコレ
クションスレッドをインクリメンタルに行うステップ
と、スレッドの優先度に応じて各スレッドを時分割に実
行するためのスケジューリングを行うステップと、前記
ガベージコレクションスレッドの優先度をガベージコレ
クションスレッド以外のスレッドの優先度より高い状態
と低い状態とに交互に変更するステップとから成るプロ
グラム制御方法。
【請求項２０】イベントの発生に応じてリアルタイム
スレッドを実行させ、該リアルタイムスレッドの中断時
または終了時に非リアルタイムスレッドを実行させるス
テップを備えたプログラム制御方法において、前記非リアルタイムスレッドの１つは、メモリのヒープ
領域内の、どのオブジェクトからも参照されないオブジ
ェクトを検出し、当該オブジェクトのメモリ領域を他の
オブジェクトのメモリ割り当て可能なフリー領域として
解放するガベージコレクションをインクリメンタルに行
うガベージコレクションスレッドであり、当該ガベージ
コレクションスレッド以外の非リアルタイムスレッドの
実行によりヒープ領域内の前記フリー領域が所定の値ま
で減少したとき、前記ガベージコレクションスレッドを
実行するステップを備えたことを特徴とするプログラム
制御方法。
【請求項２１】メモリのヒープ領域内の、どのオブジ
ェクトからも参照されないオブジェクトを検出し、当該
オブジェクトのメモリ領域を他のオブジェクトのメモリ
割り当て可能なフリー領域として解放するとともに、前
記フリー領域または前記オブジェクトの使用領域の量に
基づいて、手順の異なる複数通りのガベージコレクショ
ンスレッドを選択的に実行することを特徴とするプログ
ラム制御方法。
【請求項２２】メモリのヒープ領域内に割り当てられ
るオブジェクトのサイズの分布を検知し、その分布中心
より大きな固定サイズの整数倍を前記ヒープ領域に対す
る新たなオブジェクトの割り当てサイズとすることを特
徴とするメモリの割り当て方法。
【請求項２３】テンプレートとしてのクラスと該クラ
スにより生成されるオブジェクトをメモリのヒープ領域
内に割り当てるメモリの割り当て方法において、前記クラスからオブジェクトが生成された時刻に相当す
るデータを記憶し、前記オブジェクトを削除する際に、
当該オブジェクトの寿命を検出し、該寿命のデータをク
ラスに設け、当該クラスからオブジェクトを生成する際
に、前記寿命のデータに基づいて、前記ヒープ領域に対
するオブジェクトの生成領域を分けることを特徴とする
メモリの割り当て方法。
【請求項２４】メモリのヒープ領域内の、他のオブジ
ェクトから参照されるオブジェクトを検出して当該参照
の有無状態を記憶し、当該記憶内容を基に、どのオブジ
ェクトからも参照されないオブジェクトのメモリ領域を
他のオブジェクトのメモリ割り当て可能な領域として解
放するメモリ割り当て方法において、オブジェクトの生成時にオブジェクトの参照関係を表す
ツリー構造の第１のデータを記憶し、参照関係の変更時
に、オブジェクトの参照関係の変更された部分のオブジ
ェクトを示す第２のデータを記憶し、第１のデータを探
索して参照されているオブジェクトを検出し、第２のデ
ータを読み出すとともに該データを基に第１のデータを
探索して、参照されているオブジェクトを検出すること
を特徴とするメモリの割り当て方法。
【請求項２５】或るスレッドからの、指定メモリ領域
に対するデータの書き込み有無検出の開始を依頼するア
プリケーションプログラムインタフェースの呼び出しに
応答して、その書き込み有無を示すフラグを書き込み無
しの状態に設定する処理プログラムと、前記指定メモリ領域に対するデータの書き込みがあった
とき、前記フラグを書き込み有りの状態に設定するステ
ップと、前記スレッドからの、指定メモリ領域に対する
データの書き込み有無検出の終了を依頼するアプリケー
ションプログラムインタフェースの呼び出しに応答し
て、前記フラグの状態に応じた値を前記スレッドに返す
処理プログラムとを記録して成るプログラム記録媒体。
【請求項２６】メモリのヒープ領域内の、どのオブジ
ェクトからも参照されないオブジェクトを検出し、当該
オブジェクトのメモリ領域を他のオブジェクトのメモリ
割り当て可能なフリー領域として解放するガベージコレ
クションスレッドをインクリメンタルに行う処理プログ
ラムと、スレッドの優先度に応じて各スレッドを時分割
に実行してスケジューリングを行う処理プログラムと、
前記ガベージコレクションスレッドの優先度をガベージ
コレクションスレッド以外のスレッドの優先度より高い
状態と低い状態とに交互に変更する処理プログラムとを
記録して成るプログラム記録媒体。
【請求項２７】イベントの発生に応じてリアルタイム
スレッドを実行し、該リアルタイムスレッドの中断時ま
たは終了時に非リアルタイムスレッドを実行するプログ
ラム制御装置に用いられるプログラム記録媒体であっ
て、前記非リアルタイムスレッドの１つを、メモリのヒープ
領域内の、どのオブジェクトからも参照されないオブジ
ェクトを検出し、当該オブジェクトのメモリ領域を他の
オブジェクトのメモリ割り当て可能なフリー領域として
解放するガベージコレクションをインクリメンタルに行
うガベージコレクションスレッドとし、当該ガベージコ
レクションスレッド以外の非リアルタイムスレッドの実
行によりヒープ領域内の前記フリー領域が所定の値まで
減少したとき、前記ガベージコレクションスレッドを実
行する処理プログラムを記録したことを特徴とするプロ
グラム記録媒体。
【請求項２８】メモリのヒープ領域内の、どのオブジ
ェクトからも参照されないオブジェクトを検出し、当該
オブジェクトのメモリ領域を他のオブジェクトのメモリ
割り当て可能なフリー領域として解放する、手順の異な
る複数通りのガベージコレクションスレッドを選択的に
実行する処理プログラムと、前記フリー領域または前記
オブジェクトの使用領域の量に基づいて、前記複数通り
の手順のうち１つの手順のガベージコレクションスレッ
ドを実行する処理プログラムとを記録して成るプログラ
ム記録媒体。
【請求項２９】プログラムの実行時にメモリのヒープ
領域内にオブジェクトを生成するコンピュータに用いら
れるプログラム記録媒体であって、メモリのヒープ領域内に割り当てられるオブジェクトの
サイズの分布を検知し、その分布の中心より大きな固定
サイズの整数倍を前記ヒープ領域に対する新たなオブジ
ェクトの割り当てサイズとする処理プログラムを記録し
て成るプログラム記録媒体。
【請求項３０】前記ヒープ領域内を予め複数のサイズ
に分割し、オブジェクト生成時に当該オブジェクトのサ
イズより大きく且つ最も小さなサイズの領域を割り当て
る処理プログラムを記録して成る請求項２９に記載のプ
ログラム記録媒体。
【請求項３１】メモリのヒープ領域内にオブジェクト
を生成する手段を備えたプログラム制御装置に用いられ
るプログラム記録媒体であって、アプリケーションプログラムインタフェースの呼び出し
によって前記固定サイズを設定する処理プログラムと、
前記固定サイズの整数倍を前記ヒープ領域内に対するオ
ブジェクトの割り当てサイズに決定する処理プログラム
を記録して成るプログラム記録媒体。
【請求項３２】メモリのヒープ領域内にオブジェクト
を生成する手段を備えたプログラム制御装置に用いられ
るプログラム記録媒体であって、前記ヒープ領域内に割り当てられるオブジェクトのサイ
ズの分布をアプリケーションプログラムインタフェース
の呼び出しによって設定し、該アプリケーションプログ
ラムインタフェースの呼び出しに応答して、前記分布の
中心より大きな値を前記固定サイズとして設定する処理
プログラムと、前記固定サイズの整数倍を前記ヒープ領
域内に対するオブジェクトの割り当てサイズに決定する
処理プログラムを記録して成るプログラム記録媒体。
【請求項３３】プログラムの実行時にテンプレートと
してのクラスによりメモリのヒープ領域にオブジェクト
を生成するコンピュータに用いられるプログラム記録媒
体であって、前記クラスからオブジェクトが生成された時刻に相当す
るデータを記憶し、前記オブジェクトを削除する際に、
当該オブジェクトの寿命を検出し、該寿命のデータをク
ラスに設け、当該クラスからオブジェクトを生成する際
に、前記寿命のデータに基づいて、前記ヒープ領域に対
するオブジェクトの生成領域を分ける処理プログラムを
記録して成るプログラム記録媒体。
【請求項３４】メモリのヒープ領域内の、他のオブジ
ェクトから参照されるオブジェクトを検出して当該参照
の有無状態を記憶し、当該記憶内容を基にオブジェクト
を消去するコンピュータに用いられるプログラム記録媒
体であって、オブジェクトの生成時にオブジェクトの参照関係を表す
ツリー構造の第１のデータを記憶し、参照関係の変更時
に、オブジェクトの参照関係の変更された部分のオブジ
ェクトを示す第２のデータを記憶し、第１のデータを探
索して参照されているオブジェクトを検出し、第２のデ
ータを読み出すとともに該データを基に第１のデータを
探索して、参照されているオブジェクトを検出する処理
プログラムを記録して成るプログラム記録媒体。