JP3826626B2 - プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 - Google Patents
プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 Download PDFInfo
- Publication number
- JP3826626B2 JP3826626B2 JP20034599A JP20034599A JP3826626B2 JP 3826626 B2 JP3826626 B2 JP 3826626B2 JP 20034599 A JP20034599 A JP 20034599A JP 20034599 A JP20034599 A JP 20034599A JP 3826626 B2 JP3826626 B2 JP 3826626B2
- Authority
- JP
- Japan
- Prior art keywords
- thread
- context switch
- area
- mark
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
- G06F12/0269—Incremental or concurrent garbage collection, e.g. in real-time systems
- G06F12/0276—Generational garbage collection
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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 the object) ：
オブジェクトが生成され、消去されるまでの時間。
【０００９】
(22) ライトバリア(write barrier) ：
オブジェクトへの参照関係の変更をチェックし、書き替えが起こった場合に何らかの処理をすること。本件の場合は、書き替えが起きたとき、書き替える参照が指しているオブジェクトに対応するマークテーブルの欄にマークを付ける。
【００１０】
(23) スイープ(sweeping)：
ヒープ領域上の不要なオブジェクトを取り除く処理。
【００１１】
(24) オブジェクト生成(create the object) ：
新しいオブジェクトを生成すること。具体的には、ヒープ領域の一部をオブジェクトに割り当て、内容を初期化すること。
【００１２】
(25) オブジェクト消去(delete the object) ：
不要なオブジェクトを取り除くこと。具体的には、ヒープ領域に確保してある領域を解放すること。
【００１３】
(26) 参照(reference) ：
或るオブジェクトＡが別の特定のオブジェクトＢにアクセスするためにオブジェクトＢを特定する情報。具体的には、オブジェクトＢを指すポインタまたはインデックス。
【００１４】
(27) 参照変更(chenge the reference / reconnect the reference) ：
参照を現在のオブジェクトＢから別のオブジェクトＣに変更すること。
【００１５】
さて、従来のシングルプロセッサのコンピュータシステムにおいて、オペレーティングシステム上で複数のスレッドを並行処理する場合、共有メモリを用いて排他制御するために、また複数のタスク間で同期をとるために、従来よりセマフォやイベントフラグなどを用いて排他制御が行われている。
【００１６】
また、例えばプログラムを少量のメモリ環境下で動作させることなどを目的として、仮想記憶を行わないで単一のアドレス空間のメモリをプログラムの実行時に動的に割り当てる、いわゆる動的記憶管理が従来より行われている。このような動的記憶管理によれば、プログラムにより明示的にメモリ領域の解放を行わなければ、プログラムの実行過程において使用されなくなったメモリ領域が発生する。その結果、プログラムが使用できるフリー領域が次第に不足する。こうした問題を回避するために、使用されなくなったメモリ領域（ガベージ）を抽出し、これらを集めて（コレクトして）再び使用可能なフリー領域とする、ガベージコレクションと呼ばれる処理を自動的に行うようにしている。
【００１７】
ここで従来のガベージコレクションの処理手順をフローチャートとして図５４に示す。ガベージコレクションのアルゴリズムにはマーク＆スイープ法、複写法、参照カウント法などの各種方法が考えられているが、ここではマーク＆スイープ法について例示する。図５４に示すように、まずガベージコレクションの途中でガベージコレクションスレッド以外の他のスレッドが実行されないように割り込みを禁止し、シングルスレッドモードにする(s201)。続いてメモリ上のガベージコレクションの対象となる領域（以下「ヒープ領域」という。）に割り当てられているオブジェクトにそれぞれ対応するマークの記憶領域（以下「マークテーブル」という。）をクリアする(s202)。続いてヒープ領域内に割り当てられているオブジェクトの参照関係を示す情報を基に何れかのオブジェクから参照されているオブジェクトを検出し、それらに対応するマークテーブル上の位置にマークを付ける処理を行う(s203)。この処理により、何れのオブジェクトからも参照されていないオブジェクトはもはや使われなくなったオブジェクトであり、それに相当するマークテーブルにはマークが付けられないことになる。従ってそのマークしていないオブジェクトを新たなオブジェクトの割当可能な領域、すなわちフリー領域として抽出する(s204)。例えばこのフリー領域をリスト構造のデータとして生成する。その後、割り込み禁止を解除し、マルチスレッドのモードに戻す(s205)。
【００１８】
従来はこのようなガベージコレクションが、メモリのフリー領域が所定量まで減少した時点で自動的に起動されるようにしていた。
【００１９】
また、ガベージコレクションを行ったとき、任意の大きさ（メモリサイズ）のオブジェクトが任意に解放されるのでフラグメントが発生する。そこで、連続したサイズの大きな領域がとれるように、オブジェクトの割当領域を例えば先頭から順次詰めるメモリコンパクション（以下単に「コンパクション」という。）を実行していた。
【００２０】
【発明が解決しようとする課題】
上述した排他制御の機能をセマフォやイベントフラグなどのコンピュータ資源を用いることで実現している従来のシステムにおいては、その資源が他のスレッドなどで使用されている場合には、他のスレッドはその資源が解放されるのを待たなければならない。このような資源待ちの時間が生じると、リアルタイム性の要求されるシステムにおいては大きな障害となる。すなわち、資源待ち状態にあるスレッドは、その資源が解放されるまで、処理できずリアルタイムな応答が不可能となる。
【００２１】
例えば上記従来のガベージコレクション（以下「ＧＣ」という。）の方法によれば、メモリ空間が広いほど、ガベージとしてコレクトしてもよい領域を見つけ出すのに時間がかかり、例えば６４〜１２８ＭＢのヒープ領域で数秒間を要し、且つＧＣはフリー領域がある程度減少した時点で不定期に行われるので、リアルタイム性の要求されるシステムには用いることができなかった。
【００２２】
リアルタイム性の要求されるシステムでは、あるタスクを実行中に何らかのイベント（割り込み）が発生すれば、そのイベントに応じた他のスレッドを処理することになるが、そのスレッドの切替に要する時間は、最悪値として例えば数十μｓｅｃ以下であることが要求される。ところが、上述したようにＧＣが何時起動されるか予測できず、一旦起動されれば、ＣＰＵは数秒間ＧＣに専念することになるため、その間リアルタイム処理は不可能となる。
【００２３】
上述の問題はＧＣの場合に限らず、長時間の資源待ち状態が生じるシステムに共通の問題である。
【００２４】
この発明の目的はセマフォやイベントフラグなどのコンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性を保証することにより、上述の問題を解消することにある。
ここで、先行技術調査を行った際に発見した文献について示しておく。
【００２５】
(1) Incremental Garbage Collection of Concurrent Objects for Real-Time Application
この論文は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 pp586-592
マルチメディアオペレーティングシステムのコンセプトが示されている。
【００３０】
(7) 日本ソフトウェア科学会第１２回Ｄ７−４
スタック上のオブジェクトの一番上にオブジェクトの大きさを書いておくことが示されている。
(8) 11TH Real-Time System Symposium "Incremental Garbage Collection of Concurrent Object for Real-Time Applications"
オブジェクト間の参照ツリーの考え方が示されている。
【００３１】
(9) 情報処理学会第３８回全国大会5U-7
オブジェクトの寿命に関連してメモリ割当を行うことが示されている。
【００３２】
(10)Lecture Notes in Computer Science 259 "Garbage Collection in a Distributed Environment"
アプリケーションプログラムインタフェースの呼出に応じてＧＣを制御することと、オブジェクト参照に関する技術思想が示されている。
【００３３】
【課題を解決するための手段】
この発明は、上記課題を解決するために、以下の構成を備えている。
指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のアプリケーションプログラムインタフェースを処理開始前に発行し、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のアプリケーションプログラムインタフェースを処理終了後に発行するスレッドを実行する実行手段と、
前記スレッドにより、前記第１のアプリケーションプログラムインタフェースが発行された場合に、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無を示すコンテキストスイッチフラグの状態を書き込み無しと判定する状態に設定する第１の設定手段と、
コンテキストスイッチの発生にともなって、前記指定メモリ領域に対するデータの書き込みがあったと判断したとき、前記コンテキストスイッチフラグの状態を書き込み有りと判定する状態に設定する第２の設定手段と、
前記スレッドにより、前記第２のアプリケーションプログラムインタフェースが発行された場合に、前記コンテキストスイッチフラグの状態に応じた値を前記スレッドに返す手段と、を備えたことを特徴とする。
【００３４】
この構成では、コンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性が保証される。すなわち指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のＡＰＩの呼び出しから指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のＡＰＩの呼び出しまでの間で行われたスレッドＡの処理の途中で、他のスレッドによる指定メモリ領域に対する書き込みがあったか否かが、そのスレッドＡで分かる。書き込みが行われていなければ、指定メモリ領域の排他性が保たれている。もし書き込みが行われていれば、スレッドＡのその間の処理を無効にして、例えばその処理を再度実行するなどの方法によって高い応答性を保ちながら、排他制御を行うことができるようになる。
【００３６】
【発明の実施の形態】
以下、この発明の実施形態であるプログラム制御装置について、図１〜図５３を参照して順次説明する。
【００３７】
図１は装置のハードウエアの構成を示すブロック図である。装置は基本的にＣＰＵ１とオブジェクト群を生成するヒープ領域およびマークテーブル等を記憶するメモリ２、および外部との入出力を行うＩ／Ｏ３とから構成する。また、外部から必要なプログラムをメモリにロードする場合は、ＣＤ−ＲＯＭ読取インタフェース４を用い、プログラムが予め書き込まれたＣＤ−ＲＯＭ５を読み取るようにする。このＣＤ−ＲＯＭが本願発明に係るプログラム記録媒体に相当する。
図２はソフトウエアの構成を示すブロック図である。同図において、カーネル部分はＣＰＵやメモリを資源として管理し、時分割によるマルチスレッドの機能を実現する。ＶＭ（仮想マシーン）部分はプログラムとカーネルとのインタフェースを行うソフトウエアであり、ここではアプリケーションプログラムから見てＶＭ以下の階層全体が例えばＪａｖａ仮想マシンとして作用させる。（Ｊａｖａは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 マークでなければ、すでにマークされているので、そのまま処理を終了する。White マークであれば、それをGrayにマークする（ｓ１９３）。上述したようにこのGrayマークは参照変更のあったオブジェクトであることを意味する。続いてマークスタックに参照先のオブジェクトを示すデータを積む（ｓ１９４）。
【０１０１】
図４８は上記「オブジェクトに対応するマーク付与」の処理手順を示すフローチャートである。この処理は、生成されているオブジェクトからマークテーブル上の位置を計算し、Black マークを付与する。このBlack マークは上述したように、マークされている状態を意味する。なお、「オブジェクトの生成」の処理は図３９に示したものと同様である。
【０１０２】
このように、参照変更のあったオブジェクトについてマークを付与する場合、そのオブジェクトが初めて検出されたオブジェクトである場合にのみマークを付与するようにしたため、マークスタックの内容によるツリー探索に要する時間およびマークスタックの読み出しに要する時間を短縮化できる。
【０１０３】
なお、参照変更のあったオブジェクトについてのマークを記憶するのはスタックでなくてもよく、ＦＩＦＯのバッファを用いてもよい。
【０１０４】
また、実施形態ではマークテーブルにマークを付与するようにしたが、オブジェクトの内部にマーク用の情報を設けて、オブジェクトに直接マークを付与するようにしてもよい。
【０１０５】
【発明の効果】
この発明によれば、コンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性が保証される。すなわち指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼するＡＰＩの呼び出しから指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼するＡＰＩの呼び出しまでの間で行われたスレッドＡの処理の途中で、他のスレッドによる指定メモリ領域に対する書き込みがあったか否かが、そのスレッドＡで分かる。書き込みが行われていなければ、指定メモリ領域の排他性が保たれている。もし書き込みが行われていれば、スレッドＡのその間の処理を無効にして、例えばその処理を再度実行するなどの方法によって高い応答性を保ちながら、排他制御を行うことができるようになる。
【図面の簡単な説明】
【図１】実施形態に係る装置のハードウエアの構成を示すブロック図
【図２】同装置のソフトウエアの構成を示すブロック図
【図３】オブジェクト間の参照関係を示すツリーおよび各スレッドのスタックとの関係を示す図
【図４】ソフトウエアの機能ブロック図
【図５】コンパクションの作用を説明するための図
【図６】コンテキストスイッチの有無によるスレッドの処理内容の変化の例を示す図
【図７】排他制御の処理手順を示すフローチャート
【図８】コンテキストスイッチ発生有無検出のＡＰＩに関する処理手順を示すフローチャート
【図９】コンテキストスイッチの処理手順を示すフローチャート
【図１０】コンパクションの処理手順を示すフローチャート
【図１１】複写法によるＧＣの処理手順を示すフローチャート
【図１２】複写法ＧＣにおける排他制御の処理手順を示すフローチャート
【図１３】複写法ＧＣにおける他の排他制御の処理手順を示すフローチャート
【図１４】図１３における排他制御用ＡＰＩに関する処理手順を示すフローチャート
【図１５】図１３における排他制御用ＡＰＩに関する処理手順を示すフローチャート
【図１６】ＧＣスレッドの優先度の自動切替の例を示す図
【図１７】スレッドの優先度値および優先度時間の切替に関するフローチャート
【図１８】ＧＣスレッドの高優先度時間を変更した例を示す図
【図１９】ＧＣスレッドの高優先度時間を変更可能とするためのフローチャート
【図２０】ＧＣスレッドの高優先度時間を自動変更する例を示すフローチャート
【図２１】ＧＣスレッドの高・低優先度時間の切り替え周期を変更した例を示す図
【図２２】ＧＣスレッドの高・低優先度時間の切り替え周期を変更するためのフローチャート
【図２３】不定期なＧＣ処理の例を示す図
【図２４】図２１に対応するフローチャート
【図２５】排他制御ＡＰＩによるＧＣスレッドの優先度の強制変更の例を示す図
【図２６】排他制御ＡＰＩによるＧＣスレッドの優先度を強制変更するためのフローチャート
【図２７】ＧＣのアルゴリズムを切り替える処理手順を示すフローチャート
【図２８】生成されるオブジェクトのサイズの分布の例を示す図
【図２９】オブジェクトのメモリの割り当てサイズの例を示す図
【図３０】オブジェクト生成の処理手順を示すフローチャート
【図３１】オブジェクトサイズの分布検知および固定サイズの決定処理に関するフローチャート
【図３２】ヒープ領域の構成を示す図
【図３３】オブジェクト消去の手順を示すフローチャート
【図３４】オブジェクト生成の手順を示すフローチャート
【図３５】マーク＆スイープ法によるＧＣの手順を示すフローチャート
【図３６】マーククリアの処理手順を示すフローチャート
【図３７】オブジェクト消去の処理手順を示すフローチャート
【図３８】ツリー探索によるマーク付与の例を示す図
【図３９】図３８に対応するフローチャート
【図４０】図３８に対応するフローチャート
【図４１】図３８に対応するフローチャート
【図４２】図３８に対応するフローチャート
【図４３】ツリー探索によるマーク付与の例を示す図
【図４４】図４３に対応するフローチャート
【図４５】図４３に対応するフローチャート
【図４６】図４３に対応するフローチャート
【図４７】参照変更のマーク付与の他の処理手順を示すフローチャート
【図４８】オブジェクトに対応するマーク付与の他の処理手順を示すフローチャート
【図４９】固定サイズの設定とオブジェクト生成に関する処理手順を示すフローチャート
【図５０】オブジェクトサイズ分布設定に関する処理手順を示すフローチャート
【図５１】オブジェクトサイズの分布と分割サイズの例を示す図
【図５２】ヒープ領域を所定サイズで分割する処理とオブジェクト生成に関する処理手順を示すフローチャート
【図５３】ヒープ領域を所定サイズで分割する処理に関する処理手順を示すフローチャート
【図５４】従来のマーク＆スイープ法によるＧＣの手順を示すフローチャート
【発明の属する技術分野】
この発明は、コンピュータのプログラム制御装置、プログラム制御方法、およびプログラム記録媒体に関する。
【０００２】
【従来の技術】
先ず、本願発明の明細書において用いる各種用語の定義を以下に示す。尚、出典記号は次のとおりである。
【０００３】
ＪＩＳ：ＪＩＳ工業用語大辞典第４版（日本規格協会刊）
参１：情報技術用語事典（オーム社刊）
参２：情報処理用語大事典（オーム社刊）
参３：先端ソフトウエア用語事典（オーム社刊）
参Ａ：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 the object) ：
オブジェクトが生成され、消去されるまでの時間。
【０００９】
(22) ライトバリア(write barrier) ：
オブジェクトへの参照関係の変更をチェックし、書き替えが起こった場合に何らかの処理をすること。本件の場合は、書き替えが起きたとき、書き替える参照が指しているオブジェクトに対応するマークテーブルの欄にマークを付ける。
【００１０】
(23) スイープ(sweeping)：
ヒープ領域上の不要なオブジェクトを取り除く処理。
【００１１】
(24) オブジェクト生成(create the object) ：
新しいオブジェクトを生成すること。具体的には、ヒープ領域の一部をオブジェクトに割り当て、内容を初期化すること。
【００１２】
(25) オブジェクト消去(delete the object) ：
不要なオブジェクトを取り除くこと。具体的には、ヒープ領域に確保してある領域を解放すること。
【００１３】
(26) 参照(reference) ：
或るオブジェクトＡが別の特定のオブジェクトＢにアクセスするためにオブジェクトＢを特定する情報。具体的には、オブジェクトＢを指すポインタまたはインデックス。
【００１４】
(27) 参照変更(chenge the reference / reconnect the reference) ：
参照を現在のオブジェクトＢから別のオブジェクトＣに変更すること。
【００１５】
さて、従来のシングルプロセッサのコンピュータシステムにおいて、オペレーティングシステム上で複数のスレッドを並行処理する場合、共有メモリを用いて排他制御するために、また複数のタスク間で同期をとるために、従来よりセマフォやイベントフラグなどを用いて排他制御が行われている。
【００１６】
また、例えばプログラムを少量のメモリ環境下で動作させることなどを目的として、仮想記憶を行わないで単一のアドレス空間のメモリをプログラムの実行時に動的に割り当てる、いわゆる動的記憶管理が従来より行われている。このような動的記憶管理によれば、プログラムにより明示的にメモリ領域の解放を行わなければ、プログラムの実行過程において使用されなくなったメモリ領域が発生する。その結果、プログラムが使用できるフリー領域が次第に不足する。こうした問題を回避するために、使用されなくなったメモリ領域（ガベージ）を抽出し、これらを集めて（コレクトして）再び使用可能なフリー領域とする、ガベージコレクションと呼ばれる処理を自動的に行うようにしている。
【００１７】
ここで従来のガベージコレクションの処理手順をフローチャートとして図５４に示す。ガベージコレクションのアルゴリズムにはマーク＆スイープ法、複写法、参照カウント法などの各種方法が考えられているが、ここではマーク＆スイープ法について例示する。図５４に示すように、まずガベージコレクションの途中でガベージコレクションスレッド以外の他のスレッドが実行されないように割り込みを禁止し、シングルスレッドモードにする(s201)。続いてメモリ上のガベージコレクションの対象となる領域（以下「ヒープ領域」という。）に割り当てられているオブジェクトにそれぞれ対応するマークの記憶領域（以下「マークテーブル」という。）をクリアする(s202)。続いてヒープ領域内に割り当てられているオブジェクトの参照関係を示す情報を基に何れかのオブジェクから参照されているオブジェクトを検出し、それらに対応するマークテーブル上の位置にマークを付ける処理を行う(s203)。この処理により、何れのオブジェクトからも参照されていないオブジェクトはもはや使われなくなったオブジェクトであり、それに相当するマークテーブルにはマークが付けられないことになる。従ってそのマークしていないオブジェクトを新たなオブジェクトの割当可能な領域、すなわちフリー領域として抽出する(s204)。例えばこのフリー領域をリスト構造のデータとして生成する。その後、割り込み禁止を解除し、マルチスレッドのモードに戻す(s205)。
【００１８】
従来はこのようなガベージコレクションが、メモリのフリー領域が所定量まで減少した時点で自動的に起動されるようにしていた。
【００１９】
また、ガベージコレクションを行ったとき、任意の大きさ（メモリサイズ）のオブジェクトが任意に解放されるのでフラグメントが発生する。そこで、連続したサイズの大きな領域がとれるように、オブジェクトの割当領域を例えば先頭から順次詰めるメモリコンパクション（以下単に「コンパクション」という。）を実行していた。
【００２０】
【発明が解決しようとする課題】
上述した排他制御の機能をセマフォやイベントフラグなどのコンピュータ資源を用いることで実現している従来のシステムにおいては、その資源が他のスレッドなどで使用されている場合には、他のスレッドはその資源が解放されるのを待たなければならない。このような資源待ちの時間が生じると、リアルタイム性の要求されるシステムにおいては大きな障害となる。すなわち、資源待ち状態にあるスレッドは、その資源が解放されるまで、処理できずリアルタイムな応答が不可能となる。
【００２１】
例えば上記従来のガベージコレクション（以下「ＧＣ」という。）の方法によれば、メモリ空間が広いほど、ガベージとしてコレクトしてもよい領域を見つけ出すのに時間がかかり、例えば６４〜１２８ＭＢのヒープ領域で数秒間を要し、且つＧＣはフリー領域がある程度減少した時点で不定期に行われるので、リアルタイム性の要求されるシステムには用いることができなかった。
【００２２】
リアルタイム性の要求されるシステムでは、あるタスクを実行中に何らかのイベント（割り込み）が発生すれば、そのイベントに応じた他のスレッドを処理することになるが、そのスレッドの切替に要する時間は、最悪値として例えば数十μｓｅｃ以下であることが要求される。ところが、上述したようにＧＣが何時起動されるか予測できず、一旦起動されれば、ＣＰＵは数秒間ＧＣに専念することになるため、その間リアルタイム処理は不可能となる。
【００２３】
上述の問題はＧＣの場合に限らず、長時間の資源待ち状態が生じるシステムに共通の問題である。
【００２４】
この発明の目的はセマフォやイベントフラグなどのコンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性を保証することにより、上述の問題を解消することにある。
ここで、先行技術調査を行った際に発見した文献について示しておく。
【００２５】
(1) Incremental Garbage Collection of Concurrent Objects for Real-Time Application
この論文は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 pp586-592
マルチメディアオペレーティングシステムのコンセプトが示されている。
【００３０】
(7) 日本ソフトウェア科学会第１２回Ｄ７−４
スタック上のオブジェクトの一番上にオブジェクトの大きさを書いておくことが示されている。
(8) 11TH Real-Time System Symposium "Incremental Garbage Collection of Concurrent Object for Real-Time Applications"
オブジェクト間の参照ツリーの考え方が示されている。
【００３１】
(9) 情報処理学会第３８回全国大会5U-7
オブジェクトの寿命に関連してメモリ割当を行うことが示されている。
【００３２】
(10)Lecture Notes in Computer Science 259 "Garbage Collection in a Distributed Environment"
アプリケーションプログラムインタフェースの呼出に応じてＧＣを制御することと、オブジェクト参照に関する技術思想が示されている。
【００３３】
【課題を解決するための手段】
この発明は、上記課題を解決するために、以下の構成を備えている。
指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のアプリケーションプログラムインタフェースを処理開始前に発行し、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のアプリケーションプログラムインタフェースを処理終了後に発行するスレッドを実行する実行手段と、
前記スレッドにより、前記第１のアプリケーションプログラムインタフェースが発行された場合に、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無を示すコンテキストスイッチフラグの状態を書き込み無しと判定する状態に設定する第１の設定手段と、
コンテキストスイッチの発生にともなって、前記指定メモリ領域に対するデータの書き込みがあったと判断したとき、前記コンテキストスイッチフラグの状態を書き込み有りと判定する状態に設定する第２の設定手段と、
前記スレッドにより、前記第２のアプリケーションプログラムインタフェースが発行された場合に、前記コンテキストスイッチフラグの状態に応じた値を前記スレッドに返す手段と、を備えたことを特徴とする。
【００３４】
この構成では、コンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性が保証される。すなわち指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のＡＰＩの呼び出しから指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のＡＰＩの呼び出しまでの間で行われたスレッドＡの処理の途中で、他のスレッドによる指定メモリ領域に対する書き込みがあったか否かが、そのスレッドＡで分かる。書き込みが行われていなければ、指定メモリ領域の排他性が保たれている。もし書き込みが行われていれば、スレッドＡのその間の処理を無効にして、例えばその処理を再度実行するなどの方法によって高い応答性を保ちながら、排他制御を行うことができるようになる。
【００３６】
【発明の実施の形態】
以下、この発明の実施形態であるプログラム制御装置について、図１〜図５３を参照して順次説明する。
【００３７】
図１は装置のハードウエアの構成を示すブロック図である。装置は基本的にＣＰＵ１とオブジェクト群を生成するヒープ領域およびマークテーブル等を記憶するメモリ２、および外部との入出力を行うＩ／Ｏ３とから構成する。また、外部から必要なプログラムをメモリにロードする場合は、ＣＤ−ＲＯＭ読取インタフェース４を用い、プログラムが予め書き込まれたＣＤ−ＲＯＭ５を読み取るようにする。このＣＤ−ＲＯＭが本願発明に係るプログラム記録媒体に相当する。
図２はソフトウエアの構成を示すブロック図である。同図において、カーネル部分はＣＰＵやメモリを資源として管理し、時分割によるマルチスレッドの機能を実現する。ＶＭ（仮想マシーン）部分はプログラムとカーネルとのインタフェースを行うソフトウエアであり、ここではアプリケーションプログラムから見てＶＭ以下の階層全体が例えばＪａｖａ仮想マシンとして作用させる。（Ｊａｖａは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 マークでなければ、すでにマークされているので、そのまま処理を終了する。White マークであれば、それをGrayにマークする（ｓ１９３）。上述したようにこのGrayマークは参照変更のあったオブジェクトであることを意味する。続いてマークスタックに参照先のオブジェクトを示すデータを積む（ｓ１９４）。
【０１０１】
図４８は上記「オブジェクトに対応するマーク付与」の処理手順を示すフローチャートである。この処理は、生成されているオブジェクトからマークテーブル上の位置を計算し、Black マークを付与する。このBlack マークは上述したように、マークされている状態を意味する。なお、「オブジェクトの生成」の処理は図３９に示したものと同様である。
【０１０２】
このように、参照変更のあったオブジェクトについてマークを付与する場合、そのオブジェクトが初めて検出されたオブジェクトである場合にのみマークを付与するようにしたため、マークスタックの内容によるツリー探索に要する時間およびマークスタックの読み出しに要する時間を短縮化できる。
【０１０３】
なお、参照変更のあったオブジェクトについてのマークを記憶するのはスタックでなくてもよく、ＦＩＦＯのバッファを用いてもよい。
【０１０４】
また、実施形態ではマークテーブルにマークを付与するようにしたが、オブジェクトの内部にマーク用の情報を設けて、オブジェクトに直接マークを付与するようにしてもよい。
【０１０５】
【発明の効果】
この発明によれば、コンピュータ資源をロックのメカニズムとして使用せずに、処理の排他性が保証される。すなわち指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼するＡＰＩの呼び出しから指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼するＡＰＩの呼び出しまでの間で行われたスレッドＡの処理の途中で、他のスレッドによる指定メモリ領域に対する書き込みがあったか否かが、そのスレッドＡで分かる。書き込みが行われていなければ、指定メモリ領域の排他性が保たれている。もし書き込みが行われていれば、スレッドＡのその間の処理を無効にして、例えばその処理を再度実行するなどの方法によって高い応答性を保ちながら、排他制御を行うことができるようになる。
【図面の簡単な説明】
【図１】実施形態に係る装置のハードウエアの構成を示すブロック図
【図２】同装置のソフトウエアの構成を示すブロック図
【図３】オブジェクト間の参照関係を示すツリーおよび各スレッドのスタックとの関係を示す図
【図４】ソフトウエアの機能ブロック図
【図５】コンパクションの作用を説明するための図
【図６】コンテキストスイッチの有無によるスレッドの処理内容の変化の例を示す図
【図７】排他制御の処理手順を示すフローチャート
【図８】コンテキストスイッチ発生有無検出のＡＰＩに関する処理手順を示すフローチャート
【図９】コンテキストスイッチの処理手順を示すフローチャート
【図１０】コンパクションの処理手順を示すフローチャート
【図１１】複写法によるＧＣの処理手順を示すフローチャート
【図１２】複写法ＧＣにおける排他制御の処理手順を示すフローチャート
【図１３】複写法ＧＣにおける他の排他制御の処理手順を示すフローチャート
【図１４】図１３における排他制御用ＡＰＩに関する処理手順を示すフローチャート
【図１５】図１３における排他制御用ＡＰＩに関する処理手順を示すフローチャート
【図１６】ＧＣスレッドの優先度の自動切替の例を示す図
【図１７】スレッドの優先度値および優先度時間の切替に関するフローチャート
【図１８】ＧＣスレッドの高優先度時間を変更した例を示す図
【図１９】ＧＣスレッドの高優先度時間を変更可能とするためのフローチャート
【図２０】ＧＣスレッドの高優先度時間を自動変更する例を示すフローチャート
【図２１】ＧＣスレッドの高・低優先度時間の切り替え周期を変更した例を示す図
【図２２】ＧＣスレッドの高・低優先度時間の切り替え周期を変更するためのフローチャート
【図２３】不定期なＧＣ処理の例を示す図
【図２４】図２１に対応するフローチャート
【図２５】排他制御ＡＰＩによるＧＣスレッドの優先度の強制変更の例を示す図
【図２６】排他制御ＡＰＩによるＧＣスレッドの優先度を強制変更するためのフローチャート
【図２７】ＧＣのアルゴリズムを切り替える処理手順を示すフローチャート
【図２８】生成されるオブジェクトのサイズの分布の例を示す図
【図２９】オブジェクトのメモリの割り当てサイズの例を示す図
【図３０】オブジェクト生成の処理手順を示すフローチャート
【図３１】オブジェクトサイズの分布検知および固定サイズの決定処理に関するフローチャート
【図３２】ヒープ領域の構成を示す図
【図３３】オブジェクト消去の手順を示すフローチャート
【図３４】オブジェクト生成の手順を示すフローチャート
【図３５】マーク＆スイープ法によるＧＣの手順を示すフローチャート
【図３６】マーククリアの処理手順を示すフローチャート
【図３７】オブジェクト消去の処理手順を示すフローチャート
【図３８】ツリー探索によるマーク付与の例を示す図
【図３９】図３８に対応するフローチャート
【図４０】図３８に対応するフローチャート
【図４１】図３８に対応するフローチャート
【図４２】図３８に対応するフローチャート
【図４３】ツリー探索によるマーク付与の例を示す図
【図４４】図４３に対応するフローチャート
【図４５】図４３に対応するフローチャート
【図４６】図４３に対応するフローチャート
【図４７】参照変更のマーク付与の他の処理手順を示すフローチャート
【図４８】オブジェクトに対応するマーク付与の他の処理手順を示すフローチャート
【図４９】固定サイズの設定とオブジェクト生成に関する処理手順を示すフローチャート
【図５０】オブジェクトサイズ分布設定に関する処理手順を示すフローチャート
【図５１】オブジェクトサイズの分布と分割サイズの例を示す図
【図５２】ヒープ領域を所定サイズで分割する処理とオブジェクト生成に関する処理手順を示すフローチャート
【図５３】ヒープ領域を所定サイズで分割する処理に関する処理手順を示すフローチャート
【図５４】従来のマーク＆スイープ法によるＧＣの手順を示すフローチャート
Claims (3)
- 指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のアプリケーションプログラムインタフェースを処理開始前に発行し、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のアプリケーションプログラムインタフェースを処理終了後に発行するスレッドを実行する実行手段と、
前記スレッドにより、前記第１のアプリケーションプログラムインタフェースが発行された場合に、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無を示すコンテキストスイッチフラグの状態を書き込み無しと判定する状態に設定する第１の設定手段と、
コンテキストスイッチの発生にともなって、前記指定メモリ領域に対するデータの書き込みがあったと判断したとき、前記コンテキストスイッチフラグの状態を書き込み有りと判定する状態に設定する第２の設定手段と、
前記スレッドにより、前記第２のアプリケーションプログラムインタフェースが発行された場合に、前記コンテキストスイッチフラグの状態に応じた値を前記スレッドに返す手段と、を備えたことを特徴とするプログラム制御装置。 - 指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のアプリケーションプログラムインタフェースを処理開始前に発行し、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のアプリケーションプログラムインタフェースを処理終了後に発行するスレッドを実行するステップと、
前記スレッドにより、前記第１のアプリケーションプログラムインタフェースが発行された場合に、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無を示すコンテキストスイッチフラグの状態を書き込み無しと判定する状態に設定するステップと、
コンテキストスイッチの発生にともなって、前記指定メモリ領域に対するデータの書き込みがあったと判断したとき、前記コンテキストスイッチフラグの状態を書き込み有りと判定する状態に設定するステップと、
前記スレッドにより、前記第２のアプリケーションプログラムインタフェースが発行された場合に、前記コンテキストスイッチフラグの状態に応じた値を前記スレッドに返すステップと、をコンピュータに実行させることを特徴とするプログラム制御方法。 - 指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の開始を依頼する第１のアプリケーションプログラムインタフェースを処理開始前に発行し、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無検出の終了を依頼する第２のアプリケーションプログラムインタフェースを処理終了後に発行するスレッドを実行するステップと、
前記スレッドにより、前記第１のアプリケーションプログラムインタフェースが発行された場合に、前記指定メモリ領域に対するデータの書き込み有無の判定に用いるコンテキストスイッチの発生有無を示すコンテキストスイッチフラグの状態を書き込み無しと判定する状態に設定するステップと、
コンテキストスイッチの発生にともなって、前記指定メモリ領域に対するデータの書き込みがあったと判断したとき、前記コンテキストスイッチフラグの状態を書き込み有りと判定する状態に設定するステップと、
前記スレッドにより、前記第２のアプリケーションプログラムインタフェースが発行された場合に、前記コンテキストスイッチフラグの状態に応じた値を前記スレッドに返すステップと、をコンピュータに実行させる処理プログラムを記録したコンピュータ読取可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20034599A JP3826626B2 (ja) | 1997-11-21 | 1999-07-14 | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9-321766 | 1997-11-21 | ||
| JP32176697 | 1997-11-21 | ||
| JP20034599A JP3826626B2 (ja) | 1997-11-21 | 1999-07-14 | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10260427A Division JP3027845B2 (ja) | 1997-11-21 | 1998-09-14 | プログラム制御装置および方法 |
Related Child Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006021496A Division JP4333676B2 (ja) | 1997-11-21 | 2006-01-30 | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 |
| JP2006021495A Division JP4265610B2 (ja) | 1997-11-21 | 2006-01-30 | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 |
| JP2006021497A Division JP4345748B2 (ja) | 1997-11-21 | 2006-01-30 | メモリ割当装置、メモリ割当方法、およびプログラム記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000099351A JP2000099351A (ja) | 2000-04-07 |
| JP3826626B2 true JP3826626B2 (ja) | 2006-09-27 |
Family
ID=26512125
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20034599A Expired - Fee Related JP3826626B2 (ja) | 1997-11-21 | 1999-07-14 | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3826626B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11449601B2 (en) * | 2020-01-08 | 2022-09-20 | Red Hat, Inc. | Proof of code compliance and protected integrity using a trusted execution environment |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004030310A (ja) * | 2002-06-26 | 2004-01-29 | Nec Corp | オブジェクト検索装置、オブジェクト検索システム、オブジェクト検索方法及びオブジェクト検索プログラム |
| GB2397405B (en) | 2002-07-23 | 2004-12-15 | Samsung Electronics Co Ltd | Index structure of metadata, method for providing indices of metadata, and metadata searching method and apparatus using the indices of metadata |
| GB2399897B (en) * | 2003-03-26 | 2006-02-01 | Advanced Risc Mach Ltd | Memory recycling in computer systems |
| EP1766881A2 (en) * | 2004-06-30 | 2007-03-28 | Glenayre Electronics, Inc. | Load balancing in a distributed telecommunications platform |
| US8001336B2 (en) * | 2007-03-02 | 2011-08-16 | International Business Machines Corporation | Deterministic memory management in a computing environment |
| JP4778035B2 (ja) * | 2008-11-07 | 2011-09-21 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 外部資源を排他使用しながら実行される命令の実行時間の遅延を防ぐためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム |
| JP4917138B2 (ja) | 2009-10-07 | 2012-04-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オブジェクト最適配置装置、オブジェクト最適配置方法、及びオブジェクト最適配置プログラム |
| JP7047347B2 (ja) * | 2017-11-29 | 2022-04-05 | 株式会社アドヴィックス | 車両の制動制御装置 |
| CN116661985A (zh) * | 2022-10-25 | 2023-08-29 | 荣耀终端有限公司 | 一种垃圾回收的守护线程的管理方法、装置及电子设备 |
-
1999
- 1999-07-14 JP JP20034599A patent/JP3826626B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11449601B2 (en) * | 2020-01-08 | 2022-09-20 | Red Hat, Inc. | Proof of code compliance and protected integrity using a trusted execution environment |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000099351A (ja) | 2000-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3027845B2 (ja) | プログラム制御装置および方法 | |
| JP4265610B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
| US7167881B2 (en) | Method for heap memory management and computer system using the same method | |
| US7454447B1 (en) | Declarative pinning | |
| US6192517B1 (en) | Method, apparatus, and product for improved garbage collection in a memory system through the removal of reference conflicts | |
| JP4043528B2 (ja) | 部分的に再配置されたオブジェクトのインスタンスに関連する読み込みバリア及び書き込みバリアを有する有界休止時間ガーベッジコレクションシステム及びそのガーベッジコレクション方法 | |
| US7225439B2 (en) | Combining write-barriers within an inner loop with fixed step | |
| US7412580B1 (en) | Concurrent incremental garbage collector with a card table summarizing modified reference locations | |
| JP4333676B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
| US7062519B2 (en) | Incremental scanning of enormous objects to improve scheduling and pause-time behavior of garbage collection | |
| JP2002506549A (ja) | 部分的に再配置されたオブジェクトのソースインスタンスに関連する書き込みバリアを含む有界休止時間ガーベッジコレクションシステム及びその方法 | |
| EP3577567A1 (en) | Multiple stage garbage collector | |
| JP3826626B2 (ja) | プログラム制御装置、プログラム制御方法、およびプログラム記録媒体 | |
| US20040186863A1 (en) | Elision of write barriers for stores whose values are in close proximity | |
| EP3577565B1 (en) | Garbage collector | |
| JP4345748B2 (ja) | メモリ割当装置、メモリ割当方法、およびプログラム記録媒体 | |
| US7676801B1 (en) | Scanning of evacuated objects in a generation managed by the train algorithm | |
| JP2004503869A (ja) | モジュール式ガーベッジコレクタを実現するための方法および装置 | |
| US7058781B2 (en) | Parallel card table scanning and updating | |
| US7096329B2 (en) | Better placement of objects promoted into a generation managed by the train algorithm | |
| Miller et al. | Garbage collection in MultiScheme | |
| US7024437B2 (en) | Better placement of objects reachable from special objects during collection based on the train algorithm | |
| CN114051610A (zh) | 基于arena的存储器管理 | |
| CN112313631A (zh) | 闭环垃圾收集器 | |
| US7149762B1 (en) | Handling futile collections in the train algorithm through selective extension of the collection set |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051129 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060130 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060307 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060508 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060524 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060613 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060626 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |