JP3027845B2 - プログラム制御装置および方法 - Google Patents

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) を設定する。
また、ＡＰＩ＃Ｄが発行されると、上記パラメータで指
定された領域がライトされたときに例外が発生しないよ
うに、ＭＭＵに対する上記設定を解除する。そして上記
ワーク領域にセットされるフラグの状態を戻り値として
スレッドに返す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１４５】

【発明の効果】請求項１，４，５に係る発明によれば、
或るスレッドからのコンテキストスイッチ発生有無検出
の開始を依頼するＡＰＩの呼び出しからコンテキストス
イッチ発生有無検出の終了を依頼するＡＰＩの呼び出し
までの間で行われたスレッドの処理の途中で、コンテキ
ストスイッチがあったか否かが、そのスレッドで分かる
ため、コンピュータ資源をロックのメカニズムとして使
用せずに、処理の排他性が保証される。

【０１４６】また、コンテキストスイッチが発生してい
れば、その間のスレッドの処理を無効にして、例えばそ
の処理を再度実行するなどの方法によって高い応答性を
保ちながら、排他制御を行うことができるようになる。

【０１４７】さらに、或るスレッドの優先度を高い状態
と低い状態とに交互に変更するようにしておき、スレッ
ドの優先度が高い状態のとき、該スレッドの優先度が低
い状態になるまでの残時間が、必要な処理時間より短い
とき、その処理が行われることがないため、その分のＣ
ＰＵパワーを無駄にすることがなく、全体の処理を効率
よく進められる。

【０１４８】請求項２に係る発明によれば、システムを
ロックすることなく、ＧＣを開始することができるの
で、リアルタイム性を保証することができる。

【０１４９】請求項３に係る発明によれば、システムを
ロックすることなく、メモリコンパクションを開始する
ことができるので、リアルタイム性を保証することがで
きる。

【０１５０】

【０１５１】

【０１５２】

【０１５３】

【０１５４】

【０１５５】

【０１５６】

【０１５７】

【０１５８】

【０１５９】

【０１６０】

【０１６１】

【０１６２】

【０１６３】

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 栗林 博 京都府京都市右京区花園土堂町10番地 オムロン株式会社内 (56)参考文献 特開 平１−217638（ＪＰ，Ａ) 特開 平３−141442（ＪＰ，Ａ) 特開 平８−153037（ＪＰ，Ａ) 特開 平６−208502（ＪＰ，Ａ) 特開 昭61−75649（ＪＰ，Ａ) 特開 平４−38540（ＪＰ，Ａ) 発明協会公開技報・公技番号94−6618 発明協会公開技報・公技番号92−1076 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/46 G06F 12/00 G06F 9/44 G06F 12/02 G06F 11/14

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 或るスレッドからの、コンテキストスイ
   ッチ発生有無検出の開始を依頼するアプリケーションプ
   ログラムインタフェースの呼び出しに応答して、コンテ
   キストスイッチの発生有無を示すフラグをコンテキスト
   スイッチが発生していない状態に設定する手段と、 前記フラグがコンテキストスイッチの発生していない状
   態に設定された後、スケジューラによってコンテキスト
   スイッチが行われたとき、前記フラグをコンテキストス
   イッチが発生した状態に設定する手段と、 前記スレッドからの、コンテキストスイッチ発生有無検
   出の終了を依頼するアプリケーションプログラムインタ
   フェースの呼び出しに応答して、前記フラグの状態に応
   じた値を前記スレッドに返す手段と、 前記コンテキストスイッチが発生したとき、前記コンテ
   キストスイッチ発生有無検出の開始を依頼するアプリケ
   ーションプログラムインタフェースの呼び出しから前記
   コンテキストスイッチ発生有無検出の終了を依頼するア
   プリケーションプログラムインタフェースの呼び出しま
   での間の前記スレッドの処理を無効にする手段と、 前記或るスレッドの優先度を高い状態と低い状態とに交
   互に変更するとともに、前記コンテキストスイッチ発生
   有無検出の開始を依頼するアプリケーションプログラム
   インタフェースの呼び出しから前記コンテキストスイッ
   チ発生有無検出の終了を依頼するアプリケーションプロ
   グラムインタフェースの呼び出しまでの処理時間を受け
   取って、前記スレッドの優先度が高い状態のとき、該ス
   レッドの優先度が低い状態になるまでの残時間と前記処
   理時間とを比較し、前記残時間が前記処理時間より短い
   ことを検知したときに、前記スレッドの優先度を低くす
   る手段とを設けて成るプログラム制御装置。
2. 【請求項２】 前記スレッドは、メモリのヒープ領域内
   の他のいずれかのオブジェクトから参照されているオブ
   ジェクトを検出し、当該オブジェクトを前記ヒープ領域
   内の所定領域に複写する複写方式のガベージコレクショ
   ンスレッドである請求項１に記載のプログラム制御装
   置。
3. 【請求項３】 前記スレッドは、メモリのヒープ領域内
   のどのオブジェクトからも参照されないオブジェクトの
   メモリ領域を他のオブジェクトのメモリ割り当て可能な
   フリー領域として解放することにより生じるフラグメン
   トを解消するメモリコンパクションスレッドである請求
   項１に記載のプログラム制御装置。
4. 【請求項４】 或るスレッドからの、コンテキストスイ
   ッチ発生有無検出の開始を依頼するアプリケーションプ
   ログラムインタフェースの呼び出しに応答して、コンテ
   キストスイッチの発生有無を示すフラグをコンテキスト
   スイッチが発生していない状態に設定するステップと、 前記フラグがコンテキストスイッチの発生していない状
   態に設定された後、スケジューラによってコンテキスト
   スイッチが行われたとき、前記フラグをコンテキストス
   イッチが発生した状態に設定するステップと、 前記スレッドからの、コンテキストスイッチ発生有無検
   出の終了を依頼するアプリケーションプログラムインタ
   フェースの呼び出しに応答して、前記フラグの状態に応
   じた値を前記スレッドに返すステップと、前記コンテキストスイッチが発生したとき、前記コンテ
   キストスイッチ発生有無検出の開始を依頼するアプリケ
   ーションプログラムインタフェースの呼び出しから前記
   コンテキストスイッチ発生有無検出の終了を依頼するア
   プリケーションプログラムインタフェースの呼び出しま
   での間の前記スレッドの処理を無効にするステップと、 前記或るスレッドの優先度を高い状態と低い状態とに交
   互に変更するとともに、前記コンテキストスイッチ発生
   有無検出の開始を依頼するアプリケーションプログラム
   インタフェースの呼び出しから前記コンテキストスイッ
   チ発生有無検出の終了を依頼するアプリケーションプロ
   グラムインタフェースの呼び出しまでの処理時間を受け
   取って、前記スレッドの優先度が高い状態のとき、該ス
   レッドの優先度が低い状態になるまでの残時間と前記処
   理時間とを比較し、前記残時間が前記処理時間より短い
   ことを検知したとき、前記スレッドの優先度を低くする
   ステップ とから成るプログラム制御方法。
5. 【請求項５】 或るスレッドからの、コンテキストスイ
   ッチ発生有無検出の開始を依頼するアプリケーションプ
   ログラムインタフェースの呼び出しに応答して、コンテ
   キストスイッチの発生有無を示すフラグをコンテキスト
   スイッチが発生していない状態に設定する処理プログラ
   ムと、 前記フラグがコンテキストスイッチの発生していない状
   態に設定された後、スケジューラによってコンテキスト
   スイッチが行われたとき、前記フラグをコンテキストス
   イッチが発生した状態に設定する処理プログラムと、 前記スレッドからの、コンテキストスイッチ発生有無検
   出の終了を依頼するアプリケーションプログラムインタ
   フェースの呼び出しに応答して、前記フラグの状態に応
   じた値を前記スレッドに返す処理プログラムと、前記コンテキストスイッチが発生したとき、前記コンテ
   キストスイッチ発生有無検出の開始を依頼するアプリケ
   ーションプログラムインタフェースの呼び出しから前記
   コンテキストスイッチ発生有無検出の終了を依頼するア
   プリケーションプログラムインタフェースの呼び出しま
   での間の前記スレッドの処理を無効にする処理プログラ
   ムと、 前記或るスレッドの優先度を高い状態と低い状態とに交
   互に変更するとともに、前記コンテキストスイッチ発生
   有無検出の開始を依頼するアプリケーションプログラム
   インタフェースの呼び出しから前記コンテキストスイッ
   チ発生有無検出の終了を依頼するアプリケーションプロ
   グラムインタフェースの呼び出しまでの処理時間を受け
   取って、前記スレッドの優先度が高い状態のとき、該ス
   レッドの優先度が低い状態になるまでの残時間と前記処
   理時間とを比較し、前記残時間が前記処理時間より短い
   ことを検知したとき、前記スレッドの優先度を低くする
   処理プログラム とを記録して成るプログラム記録媒体。