JPH11508070A - 実行制御のためのチェックポイント復旧システム - Google Patents

実行制御のためのチェックポイント復旧システム

Info

Publication number
JPH11508070A
JPH11508070A JP9503018A JP50301897A JPH11508070A JP H11508070 A JPH11508070 A JP H11508070A JP 9503018 A JP9503018 A JP 9503018A JP 50301897 A JP50301897 A JP 50301897A JP H11508070 A JPH11508070 A JP H11508070A
Authority
JP
Japan
Prior art keywords
checkpoint
state
recovery
execution
file
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.)
Pending
Application number
JP9503018A
Other languages
English (en)
Inventor
チュン、ピー−ユー.
フアン、イェンヌン
キンタラ、チャンドラ
ヴォー、キエム−フォン
ワン、イー−ミン
Original Assignee
ルーセント テクノロジーズ
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ルーセント テクノロジーズ filed Critical ルーセント テクノロジーズ
Publication of JPH11508070A publication Critical patent/JPH11508070A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1461Backup scheduling policy

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

(57)【要約】 チェックポイント復旧システムは、ユーザアプリケーションプロセスに対して、正常実行中に、揮発性状態と、持続性状態の所望の部分とを含むプロセス状態を保存し、その後、保存された状態を復旧する。遅延チェックポイント技術により、チェックポイント実行された揮発性状態と、持続性状態の一部との間の不整合が生じるまで、持続性状態チェックポイントの設定が遅延される。本発明のチェックポイント復旧システムにより、ユーザアプリケーションプロセスは、持続性状態のうち指定した部分をチェックポイントから除外することができる。返値引数のような、復旧前プロセス状態の選択された部分を、チェックポイント実行された状態にユーザアプリケーションプロセスを復旧する前に保護して、保護された状態の復旧前の値をチェックポイントの復旧後も保持することが可能である。保持された返値は、復旧コードのセグメントが復旧後に実行されることを可能にするとともに、正常実行モードを復旧モードから区別することも可能にする。

Description

【発明の詳細な説明】 実行制御のためのチェックポイント復旧システム発明の属する技術分野 本発明は、プロセスの状態をチェックポイント実行および復旧するシステムに 関し、特に、持続するプロセス状態の遅延チェックポイントを含む、プロセス状 態を中断および復旧するシステムに関する。従来の技術 ますます、ソフトウェアアプリケーションのユーザは、ソフトウェアがソフト ウェア故障(フォルト)を起こしにくいこと、あるいは少なくとも故障に対して 耐性があることを要求している。例えば、通信交換システムのユーザは、交換シ ステムが連続して利用可能であることを要求する。さらに、通信が、銀行の自動 預払機の場合のような金融取引の場合、あるいはその他の重要なデータの場合、 顧客は最高度のデータ整合性をも要求する。 こうして、ユーザアプリケーションプロセスに結果を引き起こす可能性のある 多くのプログラミングエラーを検出するためのさまざまなソフトウェア検査デバ ッグツールが開発されている。例えば、米国カリフォルニア州SunnyvaleのPure Software,Inc.から市販されており、米国特許第5,193,180号に記載さ れている、PurifyTMソフトウェア検査ツールは、メモリアクセスエラーおよびメ モリリークを検出するシステムを提供している。PurifyTMシステムは、メモリの 各バイトのアロケーションおよび初期化ステータスをモニタする。さらに、メモ リにアクセスする各ソフトウェア命令ごとに、PurifyTMシステムはテストを実行 し、プログラムが未割当てメモリに書き込みをしていないこと、および、未初期 化あるいは未割当てのメモリから読み出しをしていないことを保証する。 PurifyTMシステムのようなソフトウェア検査デバッグツールは、ユーザアプリ ケーションプロセスにおける故障につながる可能性のある多くのプログラミング エラーを検出するための有効な基礎を提供するが、ソフトウェアデバッグプロセ ス中に確認、検証あるいは検査をいくら実行しても、すべてのソフトウェア故障 を検出して除去し、ユーザアプリケーションプログラムにおける完全な信頼性を 与えることはできない。従って、未検査の境界条件による残留故障、予測しない 例外、および、予期しない実行環境が、検査およびでバッグのプロセスを免れる ことが観察されており、プログラム実行中にトリガされるとこれらは表面化して 、アプリケーションプロセスのクラッシュあるいはハングを引き起こすことによ り、サービス中断を引き起こすことになる。 従って、ユーザアプリケーションが、損失する情報の量を最小にして、故障か ら回復することができる機構を提供することが所望される。そこで、ハードウェ アおよびソフトウェアの障害から効果的に回復して、損失する情報量を最小にす るために、いくつかのチェックポイント実行および復旧の方法が提案されている 。チェックポイント実行およびロールバック(後退復帰)回復の技術に関して一 般的には、R.Koo and S.Toueg,″Checkpointing and Rollback-Recovery for Distributed Systems″,IEEE Trans.Software Eng.,Vol.SE-13,No.1,pp.23 -31(1987年1月)に記載されている。一般に、チェックポイントおよび復 旧の技術は、正常実行中にプロセスの状態を定期的に保存し、その後、障害後に 、保存した状態を復旧する。このようにして、損失する作業の量は、復旧したチ ェックポイント以降にユーザアプリケーションによってなされた進展へと最小化 される。 注意すべき点であるが、プロセスの状態には、揮発性の状態と、持続性の状態 が含まれる。揮発性状態には、障害があると通常は失われてしまうプロセス情報 が含まれる。持続性状態には、ユーザアプリケーションプロセスの現在の実行に 関連するすべてのユーザファイルが含まれる。持続性状態は一般に障害があって も失われないが、データ整合性を維持するために、復旧した揮発性状態と同じポ イントに、持続性状態を復旧する必要がある。 既存のチェックポイント実行および復旧の技術は、揮発性状態のチェックポイ ント実行には十分に対処しているが、これらの方法は、持続性状態のチェックポ イント実行には十分に対処していない。1つのアプローチによれば、すべての持 続性状態、換言すれば、すべてのユーザファイルは、揮発性状態の各チェックポ イントでチェックポイント実行される。明らかに、この方法に伴うオーバーヘッ ドは、ほとんどのアプリケーションで非常に大きくなる。既存のUnixTMのチェッ クポイントライブラリのような別の方法は、揮発性状態のチェックポイントがと られるときにアクティブあるいはオープンしているユーザファイルのファイルデ ィスクリプタのみをチェックポイント実行する。しかし、この方法では、チェッ クポイントがとられた後にユーザファイルが作成されあるいはアクティブになっ た場合、整合性の問題に遭遇する。その理由は、プロセスが最後のチェックポイ ントに復旧される場合、最後のチェックポイント以降に新たに作成されあるいは アクティブにされたファイルに対する変更はもとに戻されないためである。この ような不整合状態は、検出されない破損ファイルを生じることがしばしば起こり 得る。 このようなチェックポイント実行および復旧の技術は多くのアプリケーション 環境で有効に機能するが、いくつかの制限がある。これらの制限は、克服されれ ば、チェックポイント実行システムの整合性および透明性を拡大するとともに、 これまで考えられなかった他のアプリケーションへの有用性も拡大する。特に、 ほとんどの従来のチェックポイント実行および復旧の技術は、障害回復に関する こと以外のチェックポイント実行および回復の利点を活用していない。 上記の説明から明らかなように、持続性状態全体、あるいはその必要な部分が 、各チェックポイントに含まれることを可能にするチェックポイント実行および 復旧の技術が必要とされている。さらに、不整合が生じるまで持続性状態のチェ ックポイント実行を遅延させる遅延チェックポイント実行および復旧の技術が必 要とされている。さらに、新しいタスクを実行するための開始点として、保存さ れた中間状態を使用することができるように、持続性状態のうちの選択した部分 を、与えられたチェックポイントから除外することも可能な、チェックポイント 実行および復旧のシステムが必要とされている。さらに、保護された状態の復旧 前の値がチェックポイントの復旧後に維持されるように、復旧前に、現在のプロ セス状態のうちの選択した部分を保護することが可能なチェックポイントおよび 復旧のシステムが必要とされている。発明の概要 一般に、本発明の1つの特徴によれば、チェックポイントおよび復旧のシステ ムは、正常実行中にプロセス状態を保存し、その後で、例えば障害後の回復モー ド中に、保存された状態を復旧するために、ユーザアプリケーションプロセスに おいてチェックポイントおよび復旧の技術を実装する。本発明の特徴によれば、 チェックポイントおよび復旧のシステムは、揮発性および持続性の両方の状態の チェックポイントを実行する。本発明のもう1つの特徴によれば、チェックポイ ントおよび復旧のシステムにより、ユーザあるいはユーザアプリケーションプロ セスは、持続性状態のうちの選択した部分を、チェックポイントから除外すべき であるとして指定することができる。このようにして、所望の中間状態をチェッ クポイント実行して、新たな処理タスクを実行するための開始点として使用する ことができる。別の実施例では、本発明のチェックポイントおよび復旧のシステ ムは、持続性状態全体、換言すれば、すべてのユーザファイルを、チェックポイ ント実行されるプロセス状態の部分から除外するために利用することが可能であ る。こうして、「クリーン」なメモリ状態のみをチェックポイント実行されるデ ータに含め、好ましくないメモリ状態が徐々に生じることを避けるためにときど きそれを復旧することが可能である。 本発明のさらにもう1つの特徴によれば、チェックポイント復旧システムによ れば、チェックポイント実行された状態にユーザアプリケーションプロセスを復 旧する前に、現在のプロセス状態のうちの選択された部分を保護して、保護され た状態の復旧前の値をチェックポイントの復旧後も保持することが可能である。 一実施例では、ユーザあるいはユーザアプリケーションプロセスは、復旧後に返 されるべき返値を指定することができる。この返値は、復旧後に実行される復旧 コードのセグメントを識別するために利用することができる。注意すべき点であ るが、復旧後には、実行は、復旧されたチェックポイントが設定された点から進 行する。従って、この返値は、正常実行モードを復旧モードから区別することも 可能である。 本発明のもう1つの特徴によれば、チェックポイント実行された状態の復旧後 にユーザアプリケーションプロセスの実行を制御する方法が実現される。この方 法において、ユーザアプリケーションプロセスは、対応するプロセス状態を有す る。本発明の方法は、 第1実行ポイントでプロセス状態の少なくとも一部をチェックポイント実行す るステップと、 少なくとも1つの変数の復旧前の値を保持して、第2実行ポイントでプロセス 状態をチェックポイント実行された状態に復旧するステップと、 復旧されたプロセス状態を用いてユーザアプリケーションプロセスの実行を再 開するステップと、 保持された復旧前の値に基づいてユーザアプリケーションプロセス中の命令を 実行するステップとからなる。 本発明のさらにもう1つの特徴によれば、ソフトウェア途中終了を引き起こす 例外状態を迂回するためにユーザアプリケーションによって使用される方法が実 現される。本発明の方法は、 アプリケーションプロセスにおいて例外状態をモニタするステップと、 例外状態の検出後、プロセスを途中終了する前に、チェックポイント位置にお いて、ユーザアプリケーションプロセスのチェックポイントを開始するステップ と、 プロセスを終了するステップと、 遅延期間後に、回復モードを示す返値引数とともにプロセスをチェックポイン ト位置に復旧するステップと、 復旧後に返値を検査し、返値が回復モードを示す場合、例外状態を迂回するこ とを試みるステップとからなる。 本発明のもう1つの特徴によれば、ユーザアプリケーションプロセスにインポ ートされたソフトウェアコンポーネント中の欠陥を許容する方法が実現される。 ユーザアプリケーションプロセスは、関連するユーザファイルを含むプロセス状 態を有し、カウンタ値によって識別される少なくとも2回の繰り返し回数だけ、 処理タスクを実行する。本発明の方法は、 ユーザアプリケーションプロセスを初期化して初期化状態を形成するステップ と、 ユーザファイルをプロセス状態のチェックポイントから除外するように指定す るステップと、 プロセス状態のうち除外されなかった部分をチェックポイント実行するステッ プと、 初期化状態およびカウンタ値に基づいて処理タスクを実行する実行ステップと 、 カウンタ値をインクリメントするステップと、 あらかじめ定義されたカウンタ値の値に対して、カウンタ値の現在の値を保持 して、プロセス状態のうちチェックポイントされた部分を復旧するステップと、 実行ステップを繰り返すステップとからなる。 本発明のさらに完全な理解は、本発明のさらに多くの特徴および利点について の理解とともに、詳細な説明および図面を参照して得られる。図面の簡単な説明 図1は、本発明によるチェックポイント実行および復旧のシステムを示す概略 ブロック図である。 図2は、ユーザアプリケーションプロセスの実行グラフであり、揮発性チェッ クポイント、持続性チェックポイントおよび代替マシンへのプロセスマイグレー ションを示す。 図3は、ユーザアプリケーションプロセスとオペレーティングシステムの間の ファイルシステムコールをモニタして、持続性状態と揮発性状態の間の不整合を 生じることになる持続性状態に対する変更を検出する割込みルーチンを示す。 図4は、最後の揮発性チェックポイント以降に変更されたファイルごとに持続 性状態のチェックポイント情報を保持する持続性チェックポイントテーブルを示 す。 図5は、ユーザアプリケーションプロセスの実行前に呼び出される例示的な実 行前チェックポイントサブルーチンを記述する流れ図である。 図6は、揮発性状態をチェックポイント実行するために呼び出される例示的な 揮発性状態チェックポイントサブルーチンを記述する流れ図である。 図7は、図3のファイルシステムコール割込みサブルーチンの例示的な実装を 記述する流れ図である。これは、変更が揮発性状態と持続性状態の間の不整合を 生じる前にユーザファイルをチェックポイント実行するために呼び出される。 図8Aおよび図8Bは、まとめて、復旧後の処理を制御することが可能な返値 とともに、指定されたチェックポイントにプロセス状態を復旧するために利用さ れる例示的な復旧サブルーチンを記述する流れ図である。 図9は、ユーザアプリケーションプロセスの実行後に呼び出されることが可能 な例示的なクリーンアップサブルーチンを記述する流れ図である。 図10は、リソース不足状態によって引き起こされるソフトウェアの途中終了 を迂回するために、本発明の機能を組み込んだサンプルソースコードを示す。 図11は、追加の入力ファイルおよびパラメータのセットの初期化状態をチェ ックポイント実行しその初期化状態にプロセス状態を復旧するために、本発明の 機能を組み込んだ、長い初期化を迂回する例示的なルーチンを記述する流れ図で ある。 図12は、クリーンなメモリ状態をチェックポイント実行し、そのクリーンな メモリ状態にプロセス状態を復旧するために、本発明の機能を組み込んだ、例示 的なメモリ再設定サブルーチンを記述する流れ図である。詳細な説明 本発明によるチェックポイント復旧システム10を図1に示す。以下でさらに 説明するように、チェックポイント復旧システム10によれば、正常実行中にプ ロセス状態を保存し、その後で、例えば障害後の回復モード中に、保存された状 態を復旧するために、ユーザアプリケーションプロセスにおいてチェックポイン トおよび復旧の技術を実装することが可能となる。このようにして、アプリケー ションプロセスによって失われる作業量は、最後のチェックポイント以降に生成 されたものに限定される。 システムアーキテクチャ 図1に示すように、ここに開示するチェックポイント復旧システム10は、ミ ニコンピュータ、ワークステーションまたはその他の汎用コンピュータ装置のよ うな処理ノード20上に実装することが可能である。処理ノード20は、少なく とも1つの処理ユニット25およびメモリ記憶デバイス30を有する。処理ノー ド20の処理ユニット25およびメモリ記憶デバイス30は、既知のように、バ ス60によって、または、ノード内通信のためのローカル処理ノード20上のプ ロセス間通信(IPC)設備によって、相互接続されることが可能である。さら に、各ノード20は、既知のように、シリアルまたはパラレルのノード間通信の ための通信リンク75へのネットワークインタフェース70によって、他のノー ドあるいはリモート集中回復コーディネータ(図示せず)と相互接続されること も可能である。ネットワークインタフェース70は、例えば、米国ペンシルヴェ ニア州ピッツバーグのFore Systems,Inc.から市販されているATMホストアダ プタカードである。このようにして、ユーザアプリケーションプロセスが、例え ば永久的なあるいは長期間のハードウェア障害により、ローカルノード20上で 回復することができない場合、ユーザアプリケーションプロセスは、リモートの 処理ノードにエクスポートされることが可能である。この技術はしばしばプロセ スマイグレーションと呼ばれる。 処理ユニット25は、単一のプロセッサとして、あるいは、並列に動作するい くつかのプロセッサとして実現することが可能である。メモリ記憶デバイス30 は、一般に不安定な揮発性メモリの領域であるが、処理ユニット25が取得、解 釈および実行することが可能な命令を格納することができる。一実施例では、揮 発性メモリ記憶デバイス30は、処理ユニット25によって実行されるプロセス 40のような各ユーザアプリケーションプロセスに関連するソフトウェアコード とともに、ユーザプロセス40によって呼び出されるチェックポイントライブラ リ関数50を格納する。さらに、揮発性メモリ記憶デバイス30は、既知のよう に、ユーザアプリケーションプロセス40、および、チェックポイント復旧ライ ブラリ関数50のそれぞれに関連するデータを記憶するデータセグメントセクシ ョン55を含む。 ユーザアプリケーションプロセス40によって呼び出されるチェックポイント ライブラリ関数50は、チェックポイント復旧ライブラリ150から選択される 。 チェックポイント復旧ライブラリ150は、ローカルに格納することも可能であ り、あるいは、ファイルシステム120のように集中ファイルシステム上に格納 することも可能である。ファイルシステム120のようなファイルシステムは、 ユーザがアクセス可能なファイルを格納するための集中倉庫を提供する。一般に 、集中ファイルシステム120は、不揮発性すなわち持続性メモリの領域であり 、電源がなくても情報を保持することができる。 以下でさらに説明するように、チェックポイント復旧ライブラリ150に含ま れる関数は、Cプログラミング言語のような高水準プログラミング言語で書かれ たユーザレベルのライブラリ関数である。チェックポイント復旧ライブラリ15 0内の関数は、正常実行中にプロセス状態を保存するために、あるいは、例えば 障害後の回復モード中に、保存された状態を復旧するために、ユーザアプリケー ションプロセスが読み出すことができる。一実施例では、チェックポイント復旧 ライブラリ150から関数を呼び出すユーザプロセス40はは、コンパイル中に 、あるいは、ダイナミックリンキングプロセスによって、呼び出される関数のコ ードとバインドされる。 図1に示すように、チェックポイント復旧ライブラリ150は、実行前チェッ クポイントサブルーチン152を有する。実行前チェックポイントサブルーチン 152はユーザアプリケーションプロセスの実行前に呼び出される。実行前チェ ックポイントサブルーチン152についてさらに詳細には図5に関して後述する 。さらに、チェックポイント復旧ライブラリ150は、揮発性状態チェックポイ ントサブルーチン154を有する。揮発性状態チェックポイントサブルーチン1 54は、ユーザアプリケーションプロセス40によって呼び出されると、揮発性 メモリ30から、ディスク100のような不揮発性メモリの領域に、揮発性状態 のコピーを格納する。チェックポイントディスク100は、処理ノード20上に ローカルに存在することも可能であり、あるいは、通信ネットワークのリモート ノード上に存在することも可能である。揮発性状態チェックポイントサブルーチ ン154についてさらに詳細には図6に関して後述する。さらに、チェックポイ ント復旧ライブラリ150は、ファイルシステムコール割込みサブルーチン15 6を有する。ファイルシステムコール割込みサブルーチン156は、持続性状態 の 所望の部分をチェックポイント実行するための遅延技術を提供する。ファイルシ ステムコール割込みサブルーチン156についてはさらに図3および図7に関し て後述する。 また、ライブラリ150は、復旧サブルーチン158を有する。復旧サブルー チン158は、ユーザアプリケーションプロセスを所望のチェックポイントに復 旧するために呼び出される。復旧サブルーチン158についてはさらに図8Aお よび図8Bに関して後述する。既に指摘したように、復旧サブルーチン158は 、持続性状態チェックポイントから除外されるユーザファイルをユーザが指定す ることを可能にする機構を提供して、ユーザアプリケーションプロセスが所望の あるいは予測可能な状態から将来の入力を処理することを可能にする。最後に、 チェックポイント復旧ライブラリ150は、クリーンアップサブルーチン160 を有する。クリーンアップサブルーチン160は、必要な場合に、作成されたチ ェックポイントファイルを削除するために、ユーザアプリケーションプロセスの 実行後に呼び出される。 さまざまな実装において、復旧サブルーチン158は、当業者には明らかなよ うに、検出された故障に応じて自動的に開始されることも可能であり、あるいは 、例えばコマンドライン入力によって、ユーザによりマニュアルで開始されるこ とも可能である。自動実装では、図1に示すように、ノード20のような各ノー ドはウォッチドッグ80を有することが可能である。ウォッチドッグ80は、そ れぞれのノード上で実行されているプロセスをモニタするエラー検出モニタ85 を含む。エラー検出モニタ85は、プロセスがハングしているかあるいはクラッ シュしたかどうかを判定するために、プロセス40のような、ノード20上で実 行されているアプリケーションプロセスを連続してモニタする。 エラー検出モニタ85によって実行されるモニタリングは、能動的であること も受動的であることも可能である。能動的モニタリング構成では、ウォッチドッ グ80は、ローカルノード20上のプロセス間通信(IPC)設備を用いてプロ セスにメッセージを定期的に送り、その返値を評価することによって、モニタさ れる各アプリケーションプロセスをポーリングしてそのプロセスの状態を判定し 、プロセスがまだアクティブであるかどうかを判断する。 受動的モニタリング構成では、各アプリケーションプロセスはライブラリ15 0からの関数を含み、この関数は、プロセス40のようなユーザアプリケーショ ンプロセスによって呼び出されると、指定された間隔で、ウォッチドッグ80へ 、プロセス40がまだアクティブであることを示すハートビート(鼓動)メッセ ージを送る。指定された間隔の終了前にウォッチドッグ80がアプリケーション プロセス40からシグナルを受信しない場合、ウォッチドッグ80は、アプリケ ーションプロセスがハングしているかあるいはクラッシュしたと推定する。 後でさらに説明するが、エラー検出モニタ85によってユーザアプリケーショ ンプロセス40における故障が検出されると、再開始サブシステム90が、後述 のように、最後のチェックポイントから、故障したアプリケーションプロセスの 再開始を行うことによって、故障したアプリケーションプロセスの回復を試みる 。再開始サブシステム90は、障害が検出されたときに復旧サブルーチン158 を呼び出して、故障したユーザアプリケーションプロセスの再開始を行う。 チェックポイントおよび復旧の概念および定義 チェックポイントおよび復旧の概念および定義に関する一般的に説明は、例え ば、Yi-Min Wang et al.,″Progressive Retry Technique for Software Error Recovery in Distributed Systems″,Proc. of 23rd IEEE Conf.on Fault-Tole rant Computing Systems(FTCS),pp.138-144(1993年6月)、あるいは、R.K oo and S.Toueg,″Checkpointing and Rollback-Recovery for Distributed Sy stems″,IEEE Trans.Software Eng.,Vol.SE-13,No.1,pp.23-31(1987年 1月)に記載されている。一般に、チェックポイントおよび復旧の技術は、損失 する作業の量を最小にするために、正常なプログラム実行中にときどきプロセス 状態を保存し、その後、例えば障害後に、保存されている状態を復旧する。 図2に、プロセス40のようなユーザアプリケーションプロセスの実行を示す 。ユーザアプリケーションプロセス40が実行を続ける間に、揮発性チェックポ イントVC1、VC2およびVC3のように、揮発性状態のチェックポイントが呼 び出される。ここで、揮発性状態という用語には、プログラムスタック、オープ ンファイルディスクリプタ、スタティック(静的)およびダイナミック(動的) デ ータセグメントのような、障害時に通常は失われてしまう情報と、オペレーティ ングシステムレジスタ、プログラムカウンタおよびスタックポインタのような、 現在のプログラム実行に本質的なオペレーティングシステムカーネルに関連する データ構造体が含まれる。 さらに、本発明の特徴によれば、ユーザアプリケーションプロセス40が、ユ ーザファイルの属性のような、持続性状態を変更するファイル操作を実行しよう とする場合、影響されるファイルは、後述のようにして、所望のファイル操作が 実行される前に、持続性チェックポイントPC3'およびPC3 によって示され るように、チェックポイント実行される。ここで、持続性状態という用語には、 ユーザアプリケーションプロセスの現在の実行に関連するすべてのユーザファイ ルが含まれる。持続性状態は一般に障害時に失われないが、持続性チェックポイ ントは、例えば障害が検出されたときにプロセスがその最後の揮発性チェックポ イントまでロールバックした場合に、持続性状態が揮発性状態と整合することを 保証する。注意すべき点であるが、持続性状態は、与えられたファイルへの更新 が、最後のチェックポイントに関連する揮発性状態と不整合になるまでは、記録 されない。後述のように、持続性チェックポイントPC3'およびPC3 によっ て、最後の揮発性チェックポイント以降の持続性状態へのすべての変更はもとに 戻される。 このようにして、「F1」で示される点で障害が検出されると、プロセスの揮 発性状態は、最後の揮発性チェックポイントVC3に関連するチェックポイント データを復旧することによって、チェックポイントVC3までロールバックする ことができる。さらに、持続性チェックポイントPC3'およびPC3 によって 、最後の揮発性チェックポイントVC3以降の持続性状態への変更はそれぞれも とに戻される。こうして、ロールバック後、持続性状態全体は、最後の揮発性チ ェックポイントVC3のときに存在したとおり、揮発性状態と整合する。注意す べき点であるが、プロセスがマシンAで再開始することができない場合、図2に 示すように、プロセスマイグレーションによって、プロセスは、マシンBのよう な代替マシン上で再開始することが可能である。 ファイルシステムコールに割り込むことによる持続性状態のモニタリング 既に指摘したように、持続性状態には、ユーザアプリケーションプロセスの現 在の実行に関連するすべてのユーザファイルが含まれる。一般に、ユーザアプリ ケーションプロセスがユーザファイルにアクセスし、それを変更することが可能 な唯一の方法は、オペレーティングシステムカーネルに送られるファイルシステ ムコールによるものである。従って、ユーザアプリケーションプロセスによって 生成される各ファイルシステムコールに割り込み、チェックポイント復旧システ ム10によって評価すれば、持続性状態への可能なすべての変更を識別すること が可能である。こうして、図3に概念的に示したように、プロセス40のような ユーザアプリケーションプロセスによって生成されるすべてのファイルシステム コールは、所望のファイル操作が実際にオペレーティングシステム300によっ て実行される前に、割込みルーチン156によって割り込まれモニタされる。こ れについては図7に関して後述する。このようにして、ファイル操作が持続性状 態に関連するファイルを変更しようとしている場合、影響されるファイルの情態 は整合性を保証するために記録することができる。 一実施例では、持続性状態チェックポイントは、図4に示す持続性チェックポ イントテーブル400に記録される。持続性チェックポイントテーブル400は 、ディスクのような持続性メモリに格納され、テーブル400が変更されるごと にディスクに格納される。各持続性チェックポイントテーブル400は、特定の ユーザアプリケーションプロセスに関連するとともに、checkpoint_idによって 識別される特定の揮発性チェックポイントに関連し、行405および410のよ うな複数の行を有する。各行は、関連する揮発性チェックポイント以降に何らか の変更を受けたユーザファイルに対応する。「ファイル名」によって示される各 ファイルごとに、持続性チェックポイントテーブル400は、変更される可能性 のある各ファイル属性ごとのエントリを有する。例えば、持続性チェックポイン トテーブル400は、各ファイルの「変更時刻」を記録するための列435と、 各ファイルの「アクセスモード」を記録するための列440と、各ファイルの現 在の「サイズ」を記録するための列445を含む。 一実施例では、テーブル400の各エントリは、与えられたファイルに対して 行が作成されるときに、「−1」のようなデフォルト値で初期化される。その後 、ファイルの属性が変更されると、現在の属性値を、変更前に記録することがで きる。このようにして、復旧されるファイルの与えられた属性が「−1」という 値である場合、その属性は変更されておらず、復旧の必要がない。図7に関して 後述するように、エントリは、ファイルシステムコール割込みサブルーチン15 6によって、持続性チェックポイントテーブル400内に作成される。さらに、 図8Aおよび図8Bに関して後述するように、checkpoint_idの値によって識別 される特定のチェックポイントの復旧中に、復旧サブルーチン158は持続性チ ェックポイントテーブル400にアクセスし、それに含まれる情報を利用して持 続性状態を復旧する。 チェックポイント復旧ライブラリ関数 実行前チェックポイントサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ150は、実行前チェ ックポイントサブルーチン152を含む。実行前チェックポイントサブルーチン 152は、ユーザアプリケーションプロセス40の実行前に実行される。例えば 、Cプログラミング言語で書かれたプログラムは、通常、″main″ルーチンを有 する最初の行から実行を開始する。従って、実行前チェックポイントサブルーチ ン152の実行は、″main″ルーチンの実行前に呼び出されるべきである。 チェックポイント復旧システム10は、挿入モードと透過モードという、チェ ックポイントを実行するための2つの動作モードを提供する。挿入モードは、ソ ースコードの所望の位置にチェックポイント関数を挿入することによって、ユー ザアプリケーションプロセスがチェックポイント機構を実装することを可能にす る。透過モードは、指定された時間間隔で自動的にチェックポイントを実行する 機構を提供する。透過モードによれば、ユーザアプリケーションプロセスは、ユ ーザアプリケーションプロセスへの変更や再コンパイルを必要とすることなく、 チェックポイント機構を組み込むことが可能となる。 後述のように、透過モードでは、あらかじめ定義された間隔でチェックポイン トを開始するために、実行前チェックポイントサブルーチン152によってクロ ックデーモンプロセスが生成される。後述のように、それぞれの指定された間隔 の終了時に、チェックポイントを開始するために、生成されたクロックデーモン プロセスの指示により、システム割込みコールがオペレーティングシステムによ って関連するユーザアプリケーションプロセスに送信される。 図5に示すように、実行前チェックポイントサブルーチン152は、ステップ 500から開始し、その後、ステップ505で、チェックポイント復旧システム 10によって要求される、オープンファイルテーブルおよび持続性チェックポイ ントテーブル400のようなデータ構造体を初期化する。 その後、ステップ520で、例えばコマンドライン上のユーザによる指定から 、あるいは、環境変数の設定から、ユーザアプリケーションプロセスが挿入モー ドで実行されているかそれとも透過モードで実行されているかを判定するテスト を実行する。ステップ520で、ユーザアプリケーションプロセスが透過モード で実行されていると判定された場合、ステップ525で、例えばforkシステムコ ールによって、クロックデーモンプロセスが生成される。既に指摘したように、 クロックデーモンプロセスは、指定された間隔でユーザアプリケーションプロセ スのチェックポイントを開始するチェックポイントタイマとして作用する。一実 施例では、チェックポイントは、谷間隔が指定されていなければ、30分ごとの ようなデフォルト間隔で開始される。 一方、ステップ520で、ユーザアプリケーションプロセスが挿入モードで実 行されていると判定された場合は、ユーザアプリケーションプロセスの実行によ って呼び出されるときにのみチェックポイントは開始される。 ステップ540で、ユーザアプリケーションプロセスに対する正しいチェック ポイントファイルが既に存在するかどうかを判定するテストが実行される。換言 すれば、このテストは、現在の実行が通常実行モードであるかそれとも回復モー ドであるかを判定する。注意すべき点であるが、ユーザアプリケーションプロセ スが正常終了すると、特に指定しない限り、図9に関して後述するように、クリ ーンアップサブルーチン160が、そのユーザアプリケーションプロセスに関連 するチェックポイントファイルを削除する。こうして、ユーザアプリケーション プロセスの開始時にチェックポイントファイルが存在する場合、例えば障害によ り前の実行が正常終了しなかったか、あるいは、ユーザアプリケーションプロセ スが、後の復旧のためにチェックポイントファイルを格納するよう要求したかの いずれかである。ステップ540で、ユーザアプリケーションプロセスに対する 正しいチェックポイントファイルが存在すると判定された場合、実行前チェック ポイントサブルーチン152は復帰し、図8Aおよび図8Bに関して後述するよ うに、存在するチェックポイントファイルに関連するデータを復旧し、復旧した チェックポイントの時点からユーザアプリケーションプロセスの実行を開始する ために、ステップ550で、復旧サブルーチン158の実行が開始される。 一方、ステップ540で、ユーザアプリケーションプロセスに対する正しいチ ェックポイントファイルが存在しないと判定された場合、実行前チェックポイン トサブルーチン152は復帰し、ステップ560で、ユーザアプリケーションプ ロセスの実行が開始される。 揮発性状態チェックポイントサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ150は、揮発性状態 チェックポイントサブルーチン154を有する。揮発性状態チェックポイントサ ブルーチン154は、透過モードでは、チェックポイントを開始すべきであると いうクロックデーモンからの割込みシグナルによって、あるいは、挿入モードで は、ユーザアプリケーションプロセスのソースコードに挿入されたチェックポイ ント関数コールが実行されるときに、呼び出される。さらに、後述のように、揮 発性状態チェックポイントサブルーチン154は、プログラムカウンタの値が復 旧された後に間接的に復旧サブルーチン158から呼び出される。 揮発性状態チェックポイントサブルーチン154は、ユーザアプリケーション プロセスを復旧するために必要な、障害時に失われてしまうすべての情報を保存 する。一実施例では、揮発性状態チェックポイントサブルーチン154は、各チ ェックポイント間隔を識別するために利用可能なcheckpoint_id引数を渡される 。揮発性状態チェックポイントサブルーチン154がcheckpoint_id引数を渡さ れない場合、以前のチェックポイントデータが上書きされる。checkpoint_id引 数はグローバル変数とすることにより、後で、持続性状態のチェックポイントを 実 装するファイルシステムコール割込みサブルーチン156が、適当な(現在の) 揮発性チェックポイントに持続性状態チェックポイントを関連づけるために、ア クセスすることができる。 既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウ ェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザア プリケーションプロセスの現在の実行に関連するいくつかの揮発性情報は、オペ レーティングシステムカーネルによって管理される。これらのメモリ要素は通常 はユーザアプリケーションプロセスによってアクセス可能ではないが、オペレー ティングシステムは一般に、特定のユーザアプリケーションプロセスによって要 求されるオペレーティングシステム情報をチェックポイント実行することを可能 にするルーチンを提供している。このタスクを実行するためにオペレーティング システムによって提供されるルーチンは、ステップ610で、レジスタ、スタッ クポインタおよびプログラムカウンタの内容を保存するために実行される。例え ば、Unixオペレーティングシステムは、これらのオペレーティングシステムデー タ構造体にアクセスし、宣言したグローバルデータ構造体にそれらを保存するse tjmpコールを提供している。それらのグローバルデータ構造体は、その後、揮発 性状態の一部としてチェックポイント実行することができる。setjmpシステムコ ールの動作の詳細については、例えば、W.R.Stevens,″Advanced Programming i n the Unix Environment″,pp.174-180(Addison Wesley,1992)に記載されてい る。 その後、プログラム制御はステップ620に進む。注意すべき点であるが、復 旧サブルーチン158(図8Aおよび図8B)の実行中、所望のチェックポイン トの復旧後、プログラムカウンタの値は、復旧したチェックポイントに対応する 値に復旧される。従って、プログラムカウンタの値が変更されることにより、復 旧サブルーチン158は、ステップ610の実行の直後の位置にジャンプするこ とになる。さらに注意すべき点であるが、復旧サブルーチン158は、0より大 きい返値を返す。これは、復旧後の実行のフローを制御するために利用可能であ る。例えば、あるあらかじめ定義された返値の場合にはあるコードが実行され、 別のあらかじめ定義された返値の場合には別のコードのシーケンスが実行される 。 こうして、ステップ620で、setjmpシステムコールのようなオペレーティン グシステムルーチンからの返値が0という値であるかどうかを判定するテストが 実行される。既に指摘したように、復旧サブルーチン158により、0より大き い返値を、回復モードで利用することが可能である。ステップ620で、返値が 0でないと判定された場合、挿発性状態チェックポイントサブルーチン154の 現在の実行が、回復モードで復旧サブルーチン158から呼び出されており、プ ログラム制御は、チェックポイント実行を行うことなく直接ステップ670に進 む。 一方、ステップ620で、返値が0に等しいと判定された場合、揮発性状態チ ェックポイントサブルーチン154の現在の実行は復旧サブルーチン158から 呼び出されたものではなく、揮発性状態チェックポイントサブルーチン154は 揮発性チェックポイントを続ける。すなわち、ステップ630で、揮発性チェッ クポイントの時点でオープンしているすべてのファイルのファイルディスクリプ タが、そのファイルのファイル名および現在の位置とともに、オープンファイル テーブルに格納される。オープンファイルテーブルは、各オープンファイルのフ ァイルディスクリプタ、ファイル名および位置を含む。その後、ステップ640 で、ユーザアプリケーションプロセスに関連するデータセグメントが、グローバ ル変数およびスタティック変数のようなすべての動的および静的に割り当てられ たメモリと、オープンファイルテーブルを含めて、保存される。最後に、ステッ プ650で、スタックの現在の内容が保存される。 揮発性状態チェックポイントサブルーチン154の実行はステップ670で終 了し、その後、指示された返値とともに復帰する。揮発性状態チェックポイント サブルーチン154が0の値を返す場合、これは、チェックポイントをとること に成功したことを示す。さらに、揮発性状態チェックポイントサブルーチン15 4が0より大きい値を返す場合、これは、実行のフローを制御するために利用可 能な返値とともに復旧サブルーチン158から間接的に実行が復帰していること を示す。 ファイルシステムコール割込みサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ150は、持続性状態 チェックポイントを実装するファイルシステムコール割込みサブルーチン156 を含む。ファイルシステムコール割込みサブルーチン156は、ファイルの特定 の属性を変更する可能性のあるファイルシステムコールに割り込み、必要な場合 には、持続性状態のうちの変更される部分の遅延チェックポイントを実行する。 ファイルシステムコール割込みサブルーチン156は、要求されるファイル操作 を実際に実行する前に、持続性状態チェックポイントを実行する。さらに、ファ イルシステムコール割込みサブルーチン156は、必要な限りにおいてのみ、持 続性状態のチェックポイントを実行する。 ファイルシステムコール割込みサブルーチン156は、それぞれの割り込まれ るファイルシステムコールの受信時に、ステップ700から開始する。ステップ 710で、割り込まれるファイル操作が、チェックポイントの設定を開始すべき ファイル属性を変更するかどうかを判定するテストが実行される。ステップ71 0で、割り込まれるファイル操作がチェックポイントの設定を開始すべきファイ ル属性を変更しないと判定された場合、プログラム制御はステップ750に進み 、後述のようにして所望のファイル操作を実行する。 一方、ステップ710で、割り込まれるファイル操作がチェックポイントの設 定を開始すべきファイル属性を変更すると判定された場合、ステップ720で、 ユーザが例えば関数コールを実行すること、コマンドライン引数を入力すること 、あるいは環境変数を設定することによって、現在のファイルはチェックポイン トから除外すべきであると指定したかどうかを判定するテストが実行される。こ のようにして、ユーザあるいはユーザアプリケーションプロセスは、与えられた ファイルが持続性状態チェックポイントに含まれるべきかどうかを、ファイルご とに選択的に指定することができる。 ステップ720で、現在のファイルはチェックポイントから除外すべきである と判定された場合、プログラム制御はステップ750に進み、後述のようにして 所望のファイル操作を実行する。一方、ステップ720で、現在のファイルはチ ェックポイントから除外すべきでないと判定された場合、ステップ730で、グ ローバル変数checkpoint_idの現在の値によって識別される最後の揮発性チェッ クポイント以降にこのファイルは既にチェックポイント実行されたかどうかを判 定するテストが実行される。ステップ730で、最後の揮発性チェックポイント 以降にこのファイルは既にチェックポイント実行されたと判定された場合、プロ グラム制御はステップ750に進み、後述のようにして所望のファイル操作を実 行する。 一方、ステップ730で、最後の揮発性チェックポイント以降にこのファイル は既にチェックポイント実行されてはいないと判定された場合、ステップ740 で、このファイルのシャドウコピーを作成し、ファイル名と、変更される属性の 以前の値を、checkpoint_idの現在の値に対応する持続性チェックポイントテー ブル400に追加することによって、このファイルはチェックポイント実行され る。代替実施例では、持続性状態チェックポイントは、属性ごとに各ファイルを チェックポイント実行し、現在のファイルシステムコールによって影響される属 性のみをチェックポイント実行することによって、さらに最適化することが可能 である。換言すれば、ファイル操作は全属性のうちのサブセットのみに影響し、 ファイル操作がステップ750で実行される前に、影響される属性のサブセット のみをチェックポイント実行すればよい。例えば、writeシステムコールが既存 のファイルの終端にデータを追加するのみである場合、そのファイルの、揮発性 チェックポイントにおいて存在したファイル内容は変更されないため、ファイル 内容をチェックポイント実行せず、ファイルサイズをチェックポイント実行すれ ば十分である。復旧後、このファイルは適当なサイズに切り詰めることが可能で ある。 ステップ740でファイルをチェックポイント実行した後、必要であれば、ス テップ750で、所望のファイル操作を実行することが可能である。持続性状態 チェックポイントは、ファイル操作が実行される前に記録されるため、持続性チ ェックポイントテーブル400に格納される情報は、最後の挿発性チェックポイ ント以降に各ユーザファイルになされた変更をもとに戻すために使用することが 可能である。ステップ750で、所望のファイル操作が実行された後、ファイル システムコール割込みサブルーチン156の実行はステップ760で終了し、ユ ーザアプリケーションプロセスの実行に復帰する。 復旧サブルーチン 既に指摘したように、チェックポイント復旧ライブラリ150は、図8Aおよ び図8Bに示す復旧サブルーチン158を含む。復旧サブルーチン158は、例 えば障害が検出された後にウォッチドッグ80によってアプリケーションプロセ スが正しいチェックポイントから再開始されるときに、あるいは、ユーザアプリ ケーションプロセスに対応するソースコードにロールバック関数コールが挿入さ れているときに、呼び出される。ここで、ロールバックという用語は、ユーザあ るいはユーザアプリケーションプロセスによって開始される復旧を示し、回復と いう用語は、正しいチェックポイントファイルによる障害後の復旧を示すために 用いられる。一実施例では、復旧サブルーチン158には以下の引数が渡される 。 ・mode(モード)の値は、現在の実行が回復モードであるかそれともロールバ ックモードであるかを示す。 ・checkpoint_id(チェックポイントID)の値およびreturn_value(返値) は保持され復旧サブルーチン158の実行後に返される。 ・protected_variables(保護変数)のリストは、プロセスがチェックポイン トに復旧された後であっても、復旧前の値を維持する。 注意すべき点であるが、checkpoint_idの値が指定されない場合、プロセスは最 後のチェックポイントに復旧される。さらに、return_valueが指定されない場合 、正の返値(例えば1)が用いられる。復旧サブルーチン158は、指示される チェックポイントに対応する揮発性および持続性の状態を復旧するように作用す る。後述のように、復旧サブルーチン158は、挿発性チェックポイントを復旧 し、復旧した揮発性チェックポイント以降に持続性状態になされた変更をもとに 戻すことによって、揮発性状態と持続性状態の間の整合性を保証する。 本発明の特徴によれば、復旧サブルーチン158がユーザアプリケーションプ ロセスによって呼び出されるときに、return_valueおよびprotected_variables 配列が指定される。一実施例では、復旧サブルーチン158が指示されたチェッ クポイントにロールバックするときには、protected_variables配列によって指 示される変数の現在の値が、return_value変数の現在の値とともに、保護される 。こうして、特定のチェックポイントへの復旧後、復旧の前に指定されたreturn _valueが維持され、復旧後の実行のフローを制御するために利用すること が可能である。さらに、ユーザあるいはユーザアプリケーションプロセスがすべ ての変数を特定のチェックポイントにロールバックすることを望まない場合、pr otected_variablesの機構を利用して、復旧後にも現在の値を維持すべき変数を 指定することができる。return_valueが指定されない場合、デフォルト値として 1が用いられる。 図8Aに示すように、呼び出されると、復旧サブルーチン158はステップ8 00から開始される。その後、ステップ810で、checkpoint_id引数で指示さ れる値に対応する持続性チェックポイントテーブル400(図4)が読み出され る。ステップ815で、ユーザが、例えばコマンドライン入力によってあるいは 環境変数の設定によって、持続性チェックポイントテーブル400にリストされ たシャドウファイルを復旧してはならないことを示すように、持続性チェックポ イントテーブル400が変更されるべきことを指示したかどうかを判定するテス トが実行される。ステップ815でユーザが持続性チェックポイントテーブル4 00を変更すべきであることを指示したと判定された場合、ステップ820で、 テーブル400は、指示された変更に従って変更される。 持続性チェックポイントテーブル400が変更された後、必要であれば、ステ ップ825で、テーブル400にリストされた各ファイルに対応するシャドウフ ァイルを適当なチェックポイントデータから検索し、そのシャドウファイルを現 在のファイル上にコピーすることによって、持続性チェックポイントテーブル4 00に従って持続性状態が復旧される。さらに、持続性チェックポイントテーブ ル400にリストされた各ファイルの属性が、テーブル400内のそれぞれのエ ントリに記録された値に従って変更される。 その後、ステップ830で、復旧サブルーチン158の現在の実行モードが、 障害後の回復モードであるか、それとも、ユーザが開始したロールバックモード であるか、および、protected_variables配列の値が正しいかどうかを判定する テストが実行される。ステップ830で、復旧サブルーチン158の現在の実行 モードがロールバックモードであり、protected_variables配列の値が正しいと 判定された場合、ステップ835で、チェックポイント実行されるデータセグメ ントが復旧される間にprotected_variables配列によって指定された変数を保護 するために、これらの変数がデータセグメントから一時ファイルにコピーされる 。 その後、ステップ840で、checkpoint_id引数によって識別される揮発性チ ェックポイントファイルが読み出される。ステップ845で、前のステップで取 得した揮発性チェックポイントファイルを用いて、オープンファイルテーブルを 含むデータセグメントが復旧される。 その後、ステップ850で、復旧サブルーチン158の現在の実行モードがロ ールバックモードであるかどうか、および、protected_variables配列の値が正 しいかどうかを判定するテストが再び実行される。ステップ850で、復旧サブ ルーチン158の現在の実行モードがロールバックモードであり、protected_va riables配列の値が正しいと判定された場合、ステップ855で、protected_var iables配列によって指定された変数は、一時ファイル内の保護された位置からデ ータセグメントにコピーされて戻される。このようにして、protected_variable s配列で指定される各変数は復旧前の値を維持する。 ステップ865で、ユーザが、例えばコマンドライン入力によってあるいは環 境変数の設定によって、オープンファイルテーブルを変更すべきであると指示し たかどうかを判定するテストが実行される。ステップ865で、ユーザが、オー プンファイルを変更すべきであると指示したと判定された場合、指示された変更 がステップ870で実行される。例えば、後で「長い初期化の迂回」と題する節 で説明する、本発明の特徴を含む1つのアプリケーションでは、復旧されるオー プンファイルテーブルは、以前に処理された入力ファイルの第1のセットをリス トする。処理すべき入力の後続の各セットごとに、入力ファイルの第1のセット を、現在の実行に適した入力ファイルのセットで置き換えるために、オープンフ ァイルテーブルを変更する。 オープンファイルテーブルが変更された後、必要であれば、ステップ875で 、オープンファイルテーブルに指示されるファイルディスクリプタが復旧される 。換言すれば、オープンファイルテーブル内の各エントリごとに、ファイルがオ ープンされ、ファイル名は指示されたファイルディスクリプタに関連づけられ、 ファイルの現在位置がオープンファイルテーブルエントリに記録された位置に調 整される。その後、ステップ880で、スタックスペースが割り当てられ、ステ ッ プ885で、スタックが、ステップ840で読み出された揮発性チェックポイン トファイル内の情報に従って復旧される。 既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウ ェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザア プリケーションプロセスの実行に関連するいくつかの揮発性情報は、オペレーテ ィングシステムカーネルによって管理される。これらのメモリ要素は通常はユー ザアプリケーションプロセスによってアクセス可能ではないが、オペレーティン グシステムは一般に、特定のユーザアプリケーションプロセスによって要求され るオペレーティングシステム情報を復旧することを可能にするルーチンを提供し ている。このタスクを実行するためにオペレーティングシステムによって提供さ れるルーチンは、ステップ890で、レジスタ、スタックポインタおよびプログ ラムカウンタの内容を復旧するために実行される。例えば、Unixオペレーティン グシステムは、これらのオペレーティングシステムデータ構造体を復旧するlong jmpコールを提供している。longjmpシステムコールの動作の詳細については、例 えば、W.R.Stevensの前掲書に記載されている。 既に指摘したように、プログラムカウンタの値が、チェックポイントが復旧さ れるときに記録された値に復旧されると、復旧サブルーチンの実行は、揮発性状 態チェックポイントサブルーチン154(図6)のステップ620にジャンプす る。こうして、復旧サブルーチン158は、揮発性状態チェックポイントサブル ーチン154から効果的に復帰することになる。さらに、復旧サブルーチン15 8は、指示されたreturn_valueおよびprotected_variables配列に指示された変 数を復旧前の値に維持したまま復帰する。 クリーンアップサブルーチン 既に指摘したように、チェックポイント復旧ライブラリ150は、ユーザアプ リケーションプロセスの実行後に実行されるクリーンアップサブルーチン160 を含む。図9に示すように、クリーンアップサブルーチン160は、ユーザアプ リケーションプロセスが終了したときにステップ900から開始される。ステッ プ910で、ユーザアプリケーションプロセスの現在の実行モードが透過モード であるかどうかを判定するテストが実行される。ステップ910で、現在の実行 モードが透過モードであると判定された場合、ステップ930で、実行前チェッ クポイントサブルーチン152によって生成されたクロックデーモンプロセスが 削除(kill)される。 その後、ステップ950で、ユーザアプリケーションプロセスに関連するチェ ックポイントファイルを維持すべきかどうかを判定するテストが実行される。ス テップ950で、チェックポイントファイルを保持すべきでないと判定された場 合、ステップ970で、ユーザアプリケーションプロセスに関連するチェックポ イントファイルは削除される。ステップ980で、クリーンアップサブルーチン 160は実行を終了する。 チェックポイント復旧アプリケーション ソフトウェアの途中終了の迂回 ユーザアプリケーションプロセスは、実行の継続に必要なリソースを割り当て ることができないために途中で終了することがある。ソフトウェア障害とは異な り、プロセスがリソース不足状態あるいは例外状態により途中終了するときは、 プロセスは依然として、プログラムが終了する直前の時点での制御下にある。こ こで、例外状態とは、ユーザアプリケーションプロセスによって規定される正常 な実行フロー以外の実行であると定義される。一般に、プロセスが必要なリソー ス(例えば動的メモリ)を割り当てることができないときには、プロセスは、「 リソース割当て不能」状態を示すエラーメッセージを印字し、プログラムは途中 終了する。このようなソフトウェア途中終了は、多くの有用な処理が浪費される ため、特に長時間動作したアプリケーションでは、もちろん好ましくない。一般 に、プロセスは、最初から、あるいは、おそらくは、透過チェックポイントモー ドで指定された間隔で設定された最後のチェックポイントから、再開始しなけれ ばならない。 しかし、本発明によるチェックポイント復旧システム10によれば、プロセス が終了する時点の直前で、ソースコードにチェックポイント関数コールを挿入す ることが可能である。このようにして、プロセス状態は、後で、途中終了に対応 する位置の直前の点に復旧することができる。さらに、本発明によれば、ユーザ アプリケーションプロセスが最後のチェックポイントに復旧した後の実行制御機 能を利用することによって、復旧サブルーチン158の返値は、必要であれば、 現在の実行が特殊な回復処理を開始する回復モードであることを示すことが可能 である。 図10に、例えば動的メモリを割り当てることの障害によって引き起こされた ソフトウェア途中終了を迂回するために利用可能な本発明の機能を含むソースコ ードのセグメントを示す。第1015〜1050行に示されるコード列は、第1 010行でプロセスが動的メモリを割り当てることができない限り実行される。 第1010行で実行されるmalloc関数コールは、通常Cプログラミング言語の関 数ライブラリにあるメモリ割当て関数であり、要求されたサイズのメモリブロッ クを割り当て、宣言されたポインタptrに、割り当てたメモリの開始アドレスの 値を返す。 例えば他のプロセスが残りのスワップスペースを使い尽くしてしまった場合の ように、プロセスが、所望の動的メモリを割り当てることができないとき、プロ セスは、変数MAX_RETRY_COUNTによって指定される再試行の最大回数を超えるま で、割当てを再試行する。注意すべき点であるが、再試行の規定の最大回数は0 に設定することも可能である。MAX_RETRY_COUNTを超過すると、ステップ102 5でchkpnt()(チェックポイント)が実行された後、ステップ1035でプロセ スは終了する。 既に指摘したように、プロセスが復旧されるとき、復旧サブルーチン158( 図8Aおよび図8B)が呼び出され、揮発性状態および持続性状態を最後のチェ ックポイント(換言すれば、終了の直前に実行されたチェックポイント)に復旧 する。注意すべき点であるが、復旧サブルーチン158の実行時にプログラムカ ウンタの値が復旧されると、実行は、復旧サブルーチン158から揮発性状態チ ェックポイントサブルーチン154にジャンプする。復旧サブルーチン158は 揮発性状態チェックポイントサブルーチン154へ、回復モードを示す正の返値 とともに復帰する。このように、図10の実施例では、正の返値によって、プロ グラム制御は、回復コードを実行する第1040行に進む。この例では、回復コ ードは、retry_countを0にリセットして、所望の動的メモリの割当てを再試行 することからなる。しかし、当業者には明らかなように、他の回復コードを実行 す ることも可能である。 注意すべき点であるが、リソース不足状態は過渡的である可能性があり、プロ セスが環境の変化により復旧されるときには、同じプロセスが別の条件下で実行 されて、リソース不足状態が迂回されることがある。しかし、リソース不足状態 が持続性の場合、例えば、現在のマシンが単に、ユーザアプリケーションプロセ スの要求を満たすには与えられたリソースでは十分ではない場合、途中終了を迂 回するには、より大きい容量を有する別の処理ノードへのプロセスマイグレーシ ョンが必要なこともある。本発明の技術は、プロセスをあるワークステーション 上で開始した後で、リソース不足状態に遭遇した後にのみ、より大きい容量の所 望のリソースを有する別のマシンへプロセスを移動することが可能である。 長い初期化の迂回 多くのソフトウェアプログラムは、しばしば時間のかかる初期化ルーチンを含 む。さらに、同じプログラムが相異なる入力データのセットに対して再実行され る場合、各実行において、時間のかかる初期化ルーチンを繰り返す必要があるこ とが多い。しかし、多くの場合、処理ルーチンの多くの実行が、同じ初期化され た状態を、相異なる入力データで再使用することが可能である。この場合、初期 化状態を保存し、対応するソフトウェアプログラムの将来の実行により異なる入 力データのセットで使用するために復旧することにより、ソフトウェアプログラ ムの効率は大幅に改善される。 本発明の特徴によれば、図11に示すように、与えられたソフトウェアプログ ラムに関連する初期化状態をチェックポイント実行し、後で異なる入力データに 対して実行するために復旧することができる。それぞれの異なる実行ごとに置換 される入力ファイルはチェックポイントから除外して、新しい入力ファイルをそ れぞれの新しい実行ごとに処理することが可能である。 図11に示すように、長い初期化を迂回する初期化迂回ルーチン1100はス テップ1105から開始される。まず、ステップ1110で、初期化迂回ルーチ ン1100は、例えばコマンドライン、または、入力ファイル名のセットを含む データファイルから、第1の入力パラメータのセットを読み出す。その後、ステ ップ1115で、与えられたユーザアプリケーションプロセスに適する初期化ル ーチンが実行される。ステップ1120で、チェックポイントから除外すべきフ ァイル、換言すれば、後のそれぞれの実行で置換すべきファイルが指定される。 その後、ステップ1130で、揮発性状態と、前のステップで指定されなかっ た持続性状態の部分とがチェックポイント実行される。チェックポイント関数か ら制御が戻ると、ステップ1135で、チェックポイント関数からの返値が0よ り大きい(回復モードを示す)かどうかを判定するテストが実行される。ステッ プ1135で、返値が0より大きいと判定された場合、これは、初期化迂回ルー チン1100の最初の実行であり、ステップ1150で、初期化状態と、第1の 入力ファイルおよびパラメータのセットとに従って第1のデータのセットが処理 される。 ステップ1160で、さらに処理すべき入力ファイルおよびパラメータのセッ トがあるかどうかを判定するテストが実行される。ステップ1160で、さらに 処理すべき入力ファイルおよびパラメータのセットがあると判定された場合、プ ログラム制御はステップ1170に進み、復旧サブルーチン158が正の返値で 実行される。復旧サブルーチン158は、ステップ1130で設定されたチェッ クポイントにプロセス状態を復旧する。注意すべき点であるが、ステップ113 0でチェックポイント実行されたオープンファイルテーブルは、第1の入力のセ ットに関連する各入力ファイルをリストしている。しかし、後続の実行では、オ ープンファイルテーブルにリストされた同じファイルディスクリプタのセットが 、それぞれの実行に関連する入力ファイルに関連づけられる。こうして、既に指 摘したように、復旧サブルーチン158は、ユーザがオープンファイルテーブル を変更しその変更を反映することを可能にする機構を有している。 注意すべき点であるが、ステップ1170で、プロセス状態が最後のチェック ポイントに復旧されると、プログラムカウンタも、そのチェックポイントに対応 する値に復旧され、それにより、プログラム制御は、ステップ1130で実行さ れるチェックポイント関数にジャンプする。ステップ1130で、プログラム制 御が、上記のように、正の返値でチェックポイントから復帰すると、ステップ1 135で実行されるテストの結果、プログラム制御はステップ1140に進む。 こうして、入力ファイル名のリストを含む次の入力パラメータのセットは、初期 化ルーチンの再実行を必要とせずに、上記のようなステップ1150での実行の ために、ステップ1140で読み出される。 しかし、ステップ1160で、さらに処理すべき入力ファイルおよびパラメー タのセットがないと判定されると、ステップ1180で、初期化迂回ルーチン1 100の実行は終了する。 メモリ再設定 時間が経つと、好ましくないメモリ状態が生じ、ソフトウェアプロセスの効率 的実行を妨げるとともに、システム性能を徐々に劣化して、最終的にソフトウェ ア障害を引き起こすことがある。例えば、ソフトウェアプログラムは、多くの成 功した市販品を含めて、ある実行パスに対して正しいメモリ解放を行わない場合 に、メモリリークが起こることがある。割り当てられたメモリスペースが、メモ リリークの結果、どのポインタからも参照されていないために、アクセスするこ とができなくなる。一般に、メモリリークは、割り当てられたメモリの第1ブロ ックを指すポインタが、第1ブロックを解放せずに、割当てメモリの第2ブロッ クを指すように再割当てされるときに起こる。メモリリークの結果、全体性能の 累積的な劣化が生じ、理論的には、時間が経つと、プロセスはメモリを使い果た す。 さらに、いくつかの市販のメモリマネージャによって提供されているメモリキ ャッシュおよび弱いメモリ再使用機構は、マシンが需要を満たす十分な物理的容 量を有している場合でも、メモリ不足状態を生じることがある。例えば、ユーザ アプリケーションプロセスが繰り返し小さいメモリブロック(例えば、32バイ ト以下のブロック)を要求すると、メモリマネージャは、それらの小さいブロッ クを、解放後、別のリストで、あるいは、メモリキャッシュで、小さいメモリブ ロックに対する将来の予想される要求に対して管理する。こうして、これらの小 さいブロックは、より大きいメモリ要求には利用できなくなる。小さいブロック に対する十分多くの要求があった場合、より大きいメモリ要求は、たとえ十分な 物理的容量がある場合でも、拒否されることになる。弱いメモリ再使用機構とは 、例えば30メガバイトのメモリを有するマシンが、例えば15メガバイトのメ モリをまず割り当ててから解放するような場合に関するものである。その後、ユ ー ザアプリケーションプロセスが16メガバイトの割当てを要求すると、メモリ不 足状態に遭遇する。その理由は、解放された15メガバイトに1メガバイトを追 加するのではなく、このメモリマネージャは解放された15メガバイトを予約し 、16メガバイトを割り当てようとする。この場合、実際には十分な物理的容量 があるのに、マシンのメモリ限界を超えるようにみえる。 本発明の特徴によれば、図12に示すメモリ再設定サブルーチン1200は、 プロセスのメモリを、揮発性状態の一部としての「クリーン」状態においてチェ ックポイント実行し、ソフトウェア障害を防ぐために、ときどきプロセスをその クリーン状態にロールバックする。ステップ1210で、メモリ再設定サブルー チン1200は、ループインデックスiを0にセットする。その後、ステップ1 215で、適当な初期化ルーチンを実行する。注意すべき点であるが、初期化さ れた状態は、チェックポイント実行される揮発性状態の一部である。 ステップ1220で、すべてのユーザファイルをチェックポイントから除外す るように指定する。こうして、チェックポイントが設定され、後で復旧されると きに、クリーンなメモリ状態のみが復旧されることになる。さらに、すべての持 続性状態、換言すれば、すべての入力ファイルをチェックポイントから除外する ことによって、ユーザファイルの現在の内容が復旧後に維持される。ステップ1 230で、揮発性状態チェックポイントサブルーチン154(図6)を実行する ことによって、揮発性状態がチェックポイント実行される。その後、ステップ1 240で、初期化状態およびループインデックスiの現在の値に基づいて、所望 の処理タスクが実行される。ステップ1245で、前のステップで実行された処 理タスクの結果が、周知のようにして、出力バッファに書き込まれる。出力バッ ファの内容は、バッファがフルになるまで、あるいは、flushシステムコールが 実行されるまでは、ディスクのような目的とする宛先に送られない。 ステップ1250で、さらに処理すべきループインデックスiの値があるかど うかを判定するテストが実行される。ステップ1250で、さらに処理すべきル ープインデックスiの値があると判定された場合、ステップ1255で、ループ インデックスがインクリメントされる。その後、ステップ1270で、ループイ ンデックスiの現在の値が、指定された再設定周期の倍数であるかどうがを判定 するテストが実行される。換言すれば、15回の実行ごとにクリーンなメモリ状 態を復旧すべきである場合、ループインデックスの現在の値が15の倍数である かどうかを判定するテストが実行される。ステップ1270で、ループインデッ クスiの現在の値が、指定された再設定周期の倍数でないと判定された場合、プ ログラム制御はステップ1240に戻り、上記のようにして処理を継続する。 しかし、ステップ1270で、ループインデックスiの現在の値が、指定され た再設定周期の倍数であると判定された場合、ステップ1275で、出力バッフ ァがフラッシュされた後、メモリはクリーン状態に復旧される。その後、ステッ プ1280で、返値をループインデックスiの現在の値に等しくして、復旧サブ ルーチン158を実行することによって、挿発性状態にロールバックする。チェ ックポイントはユーザファイルを含まないため、クリーンなメモリ状態のみが復 旧される。既に指摘したように、復旧サブルーチン158は、ステップ1230 で、チェックポイント関数から返値とともに復帰する。そこで、この返値(ルー プインデックスに等しい)を保持することによって、ユーザアプリケーションプ ロセスの正しい進行が保証される。復旧サブルーチン158がチェックポイント 関数から復帰すると、プログラム制御はステップ1240に進み、上記の通り継 続する。 ステップ1250で、さらに処理すべきループインデックスiの値がないと判 定された場合、プログラム制御はステップ1290に進み、メモリ再設定サブル ーチン1200の実行は終了する。 理解されるように、ここで説明した実施例およびその変形例は本発明の単なる 例示であり、当業者であれば、本発明の技術的範囲を離れることなく、さまざま な変形例を実施することが可能である。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 フアン、イェンヌン アメリカ合衆国 08807 ニュージャージ ー、サマセット カウンティ、ブリッジウ ォーター、リンバーガー ドライヴ 33 (72)発明者 キンタラ、チャンドラ アメリカ合衆国 07059 ニュージャージ ー、サマセット カウンティ、ウォーレ ン、マウンテン アヴェニュー 29 (72)発明者 ヴォー、キエム−フォン アメリカ合衆国 07922 ニュージャージ ー、ユニオン カウンティ、バークレー ハイツ、スウェンソン サークル 80 (72)発明者 ワン、イー−ミン アメリカ合衆国 07922 ニュージャージ ー、ユニオン カウンティ、バークレー ハイツ、パインウッド クレセント 10

Claims (1)

  1. 【特許請求の範囲】 1.チェックポイント実行された状態の復旧後に、プロセス状態を有するユー ザアプリケーションプロセスの実行を制御する方法において、 第1実行ポイントでプロセス状態の少なくとも一部をチェックポイント実行す るステップと、 少なくとも1つの変数の復旧前の値を保持して、第2実行ポイントでプロセス 状態をチェックポイント実行された状態に復旧するステップと、 復旧されたプロセス状態を用いてユーザアプリケーションプロセスの実行を再 開するステップと、 保持された復旧前の値に基づいてユーザアプリケーションプロセス中の命令を 実行するステップとからなることを特徴とする、復旧後にユーザアプリケーショ ンプロセスの実行を制御する方法。 2.前記保持された復旧前の値は回復モードを示すことを特徴とする請求項1 の方法。 3.前記命令は、前記回復モード中にのみ実行される命令であることを特徴と する請求項2の方法。 4.ソフトウェア途中終了を引き起こす例外状態を迂回するためにユーザアプ リケーションによって使用される方法において、 アプリケーションプロセスにおいて例外状態をモニタするステップと、 例外状態の検出後、プロセスを途中終了する前に、チェックポイント位置にお いて、ユーザアプリケーションプロセスのチェックポイントを開始するステップ と、 プロセスを終了するステップと、 遅延期間後に、回復モードを示す返値引数とともにプロセスをチェックポイン ト位置に復旧する復旧ステップと、 復旧後に返値を検査し、該返値が回復モードを示す場合、例外状態を迂回する ことを試みるステップとからなることを特徴とする、ソフトウェア途中終了を引 き起こす例外状態を迂回する方法。 5.前記例外状態を迂回する試みがあらかじめ定義された回数だけ失敗した後 にのみ、チェックポイントが開始されることを特徴とする請求項4の方法。 6.遅延された復旧により、過渡的な例外状態を迂回するのに適した環境変化 が提供されることを特徴とする請求項4の方法。 7.前記例外状態はリソース不足状態であることを特徴とする請求項4の方法 。 8.前記例外状態は所望のリソースの割当ての失敗であることを特徴とする請 求項4の方法。 9.あらかじめ定義された再試行回数だけ前記復旧ステップを再試行するステ ップと、 前記あらかじめ定義された再試行回数を超えた場合、前記プロセスを別のマシ ンに移動するステップとをさらに有することを特徴とする請求項4の方法。 10.リソース不足状態によるフトウェア途中終了を迂回するためにユーザア プリケーションによって使用される方法において、 アプリケーションプロセスにおいてリソース不足状態をモニタするステップと 、 リソース不足状態の検出後、プロセスを途中終了する前に、チェックポイント 位置において、ユーザアプリケーションプロセスのチェックポイントを開始する ステップと、 プロセスを終了するステップと、 遅延期間後に、回復モードを示す返値引数とともにプロセスをチェックポイン ト位置に復旧する復旧ステップと、 復旧後に返値を検査し、該返値が回復モードを示す場合、リソースの割当てを 試みるステップとからなることを特徴とする、リソース不足状態によるフトウェ ア途中終了を迂回する方法。 11.前記リソースの割当ての試みがあらかじめ定義された回数だけ失敗した 後にのみ、チェックポイントが開始されることを特徴とする請求項10の方法。 12.遅延された復旧により、過渡的なリソース不足状態を迂回するのに適し た環境変化が提供されることを特徴とする請求項10の方法。 13.あらかじめ定義された再試行回数だけ前記復旧ステップを再試行するス テップと、 前記あらかじめ定義された再試行回数を超えた場合、前記プロセスを別のマシ ンに移動するステップとをさらに有することを特徴とする請求項10の方法。 14.ユーザアプリケーションプロセスにインポートされたソフトウェアコン ポーネント中の欠陥を許容する方法において、 ユーザアプリケーションプロセスは、関連するユーザファイルを含むプロセス 状態を有し、 ユーザアプリケーションプロセスは、カウンタ値によって識別される少なくと も2回の繰り返し回数だけ、処理タスクを実行し、 前記方法は、 (a)ユーザアプリケーションプロセスを初期化して初期化状態を形成するス テップと、 (b)ユーザファイルをプロセス状態のチェックポイントから除外するように 指定するステップと、 (c)プロセス状態のうち除外されなかった部分をチェックポイント実行する ステップと、 (d)前記初期化状態および前記カウンタ値に基づいて処理タスクを実行する ステップと、 (e)前記カウンタ値をインクリメントするステップと、 (f)あらかじめ定義されたカウンタ値の値に対して、カウンタ値の現在の値 を保持して、プロセス状態のうちチェックポイントされた部分を復旧するステッ プと、 (g)前記ステップdを繰り返すステップとからなることを特徴とする、ユー ザアプリケーションプロセスにインポートされたソフトウェアコンポーネント中 の欠陥を許容する方法。 15.前記欠陥は、好ましくないメモリ状態を導入し、 前記ステップcは、前記好ましくないメモリ状態が導入される前に、メモリ状 態のチェックポイントを実行することを特徴とする請求項14の方法。 16.コンピュータシステム上で連続実行中にコンピュータプロセスをチェッ クポイント実行し復旧する方法において、 コンピュータプロセスは、関連するユーザファイルを含むプロセス状態を有し 、 前記方法は、 (a)チェックポイント実行されるプロセス状態からユーザファイルを除外す るステップと、 (b)プロセス状態のうち除外されなかった部分を、第1実行ポイントにおい てチェックポイント実行するステップと、 (c)少なくとも1つの復旧前の値を保持して、プロセス状態をチェックポイ ント実行された状態に、第2実行ポイントにおいて復旧するステップと、 (d)復旧されたプロセス状態を用いてプロセスの実行を再開するステップと からなることを特徴とする、コンピュータプロセスをチェックポイント実行し復 旧する方法。 17.前記ステップbは、前記コンピュータプロセス中の欠陥が好ましくない メモリ状態を導入する前に実行され、 前記ステップcは、メモリをクリーン状態に復旧することを特徴とする請求項 16の方法。 18.前記ステップcの前に、出力バッファをフラッシュするステップをさら に有することを特徴とする請求項16の方法。 19.コンピュータシステム上で連続実行中にコンピュータプロセスをチェッ クポイント実行し復旧する方法において、 コンピュータプロセスは、変数を使用し、関連するユーザファイルを含むプロ セス状態を有し、 前記方法は、 チェックポイント実行されるプロセス状態からユーザファイルを除外するステ ップと、 復旧後に保護されるべき変数を識別するステップと、 プロセス状態のうち除外されなかった部分を、第1実行ポイントにおいてチェ ックポイント実行するステップと、 識別された保護される変数の復旧前の値を保持して、プロセス状態をチェック ポイント実行された状態に、第2実行ポイントにおいて復旧するステップと、 復旧されたプロセス状態を用いてプロセスの実行を再開するステップとからな ることを特徴とする、コンピュータプロセスをチェックポイント実行し復旧する 方法。 20.コンピュータシステム上で連続実行中にコンピュータプロセスをチェッ クポイント実行し復旧するシステムにおいて、 コンピュータプロセスは、変数を使用し、関連するユーザファイルを含むプロ セス状態を有し、 前記システムは、 チェックポイント実行されるプロセス状態からユーザファイルを除外する手段 と、 復旧後に保護されるべき変数を識別する手段と、 プロセス状態の少なくとも一部のチェックポイントを記憶するメモリデバイス と、 プロセス状態のうち除外されなかった部分を、第1実行ポイントにおいてチェ ックポイント実行する手段と、 識別された保護される変数の復旧前の値を保持して、プロセス状態をチェック ポイント実行された状態に、第2実行ポイントにおいて復旧する処理手段と、 復旧されたプロセス状態を用いてプロセスの実行を再開するプロセッサとから なることを特徴とする、コンピュータプロセスをチェックポイント実行し復旧す るシステム。
JP9503018A 1995-06-16 1995-06-16 実行制御のためのチェックポイント復旧システム Pending JPH11508070A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US1995/007660 WO1997000477A1 (en) 1995-06-16 1995-06-16 Checkpoint and restoration systems for execution control

Publications (1)

Publication Number Publication Date
JPH11508070A true JPH11508070A (ja) 1999-07-13

Family

ID=22249323

Family Applications (1)

Application Number Title Priority Date Filing Date
JP9503018A Pending JPH11508070A (ja) 1995-06-16 1995-06-16 実行制御のためのチェックポイント復旧システム

Country Status (2)

Country Link
JP (1) JPH11508070A (ja)
WO (1) WO1997000477A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8356209B2 (en) 2007-03-23 2013-01-15 Microsoft Corporation Self-managed processing device
WO2013088825A1 (ja) * 2011-12-13 2013-06-20 株式会社ソニー・コンピュータエンタテインメント 情報処理装置、情報処理方法、プログラム及び情報記憶媒体
JP2013125358A (ja) * 2011-12-13 2013-06-24 Sony Computer Entertainment Inc 情報処理装置、情報処理方法、プログラム及び情報記憶媒体

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6351754B1 (en) 1998-06-23 2002-02-26 Oracle Corporation Method and system for controlling recovery downtime
US6253212B1 (en) * 1998-06-23 2001-06-26 Oracle Corporation Method and system for maintaining checkpoint values
US9971622B2 (en) * 2015-06-25 2018-05-15 Intel Corporation Technologies for application migration using lightweight virtualization
CN111625446B (zh) * 2020-04-30 2023-05-23 库卡机器人制造(上海)有限公司 软件测试方法、装置、计算机可读介质及电子设备

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4697266A (en) * 1983-03-14 1987-09-29 Unisys Corp. Asynchronous checkpointing system for error recovery
US4814971A (en) * 1985-09-11 1989-03-21 Texas Instruments Incorporated Virtual memory recovery system using persistent roots for selective garbage collection and sibling page timestamping for defining checkpoint state
US4868744A (en) * 1986-03-03 1989-09-19 International Business Machines Corporation Method for restarting a long-running, fault-tolerant operation in a transaction-oriented data base system without burdening the system log
US4819156A (en) * 1986-06-13 1989-04-04 International Business Machines Corporation Database index journaling for enhanced recovery
EP0441087B1 (en) * 1990-02-08 1995-08-16 International Business Machines Corporation Checkpointing mechanism for fault-tolerant systems
US5201044A (en) * 1990-04-16 1993-04-06 International Business Machines Corporation Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory
US5333303A (en) * 1991-03-28 1994-07-26 International Business Machines Corporation Method for providing data availability in a transaction-oriented system during restart after a failure
US5440726A (en) * 1994-06-22 1995-08-08 At&T Corp. Progressive retry method and apparatus having reusable software modules for software failure recovery in multi-process message-passing applications

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8356209B2 (en) 2007-03-23 2013-01-15 Microsoft Corporation Self-managed processing device
US8924783B2 (en) 2007-03-23 2014-12-30 Microsoft Corporation Self-managed processing device
WO2013088825A1 (ja) * 2011-12-13 2013-06-20 株式会社ソニー・コンピュータエンタテインメント 情報処理装置、情報処理方法、プログラム及び情報記憶媒体
JP2013125358A (ja) * 2011-12-13 2013-06-24 Sony Computer Entertainment Inc 情報処理装置、情報処理方法、プログラム及び情報記憶媒体
US10133604B2 (en) 2011-12-13 2018-11-20 Sony Interactive Entertainment Inc. Information processing device, information processing method, program, and information storage medium

Also Published As

Publication number Publication date
WO1997000477A1 (en) 1997-01-03

Similar Documents

Publication Publication Date Title
US6044475A (en) Checkpoint and restoration systems for execution control
US6105148A (en) Persistent state checkpoint and restoration systems
Feldman et al. Igor: A system for program debugging via reversible execution
US9323550B2 (en) Mechanism for providing virtual machines for use by multiple users
US6401216B1 (en) System of performing checkpoint/restart of a parallel program
JP3675802B2 (ja) 計算の状態を再構成する方法ならびにシステム
US5948112A (en) Method and apparatus for recovering from software faults
US6795966B1 (en) Mechanism for restoring, porting, replicating and checkpointing computer systems using state extraction
US6393583B1 (en) Method of performing checkpoint/restart of a parallel program
US8510597B2 (en) Providing restartable file systems within computing devices
EP0119806B1 (en) Asynchronous checkpointing method for error recovery
JP4321705B2 (ja) スナップショットの取得を制御するための装置及び記憶システム
US5448718A (en) Method and system for time zero backup session security
USRE37601E1 (en) Method and system for incremental time zero backup copying of data
US5454099A (en) CPU implemented method for backing up modified data sets in non-volatile store for recovery in the event of CPU failure
Bressoud TFT: A software system for application-transparent fault tolerance
US6338147B1 (en) Program products for performing checkpoint/restart of a parallel program
US6981243B1 (en) Method and apparatus to debug a program from a predetermined starting point
KR950014175B1 (ko) 데이타의 타임제로 백업 복사 방법과 수단
CN111708714B (zh) 用于有效资源回收的延迟损毁
US6256751B1 (en) Restoring checkpointed processes without restoring attributes of external data referenced by the processes
JPH11508070A (ja) 実行制御のためのチェックポイント復旧システム
Huang et al. Two techniques for transient software error recovery
US6332199B1 (en) Restoring checkpointed processes including adjusting environment variables of the processes
Ng et al. Comparing disk and memory's resistance to operating system crashes