JPH11508069A

JPH11508069A - Checkpoint and recovery system for persistent state

Info

Publication number: JPH11508069A
Application number: JP9503017A
Authority: JP
Inventors: チュン、ピー−ユー．; フアン、イェンヌン; キンタラ、チャンドラ; ヴォー、キエム−フォン; ワン、イー−ミン
Original assignee: ルーセントテクノロジーズ
Priority date: 1995-06-16
Filing date: 1995-06-16
Publication date: 1999-07-13
Also published as: WO1997000476A1

Abstract

(57)【要約】チェックポイント復旧システムは、ユーザアプリケーションプロセスに対して、正常実行中に、揮発性状態と、持続性状態の所望の部分とを含むプロセス状態を保存し、その後、保存された状態を復旧する。遅延チェックポイント技術により、チェックポイント実行された揮発性状態と、持続性状態の一部との間の不整合が生じるまで、持続性状態チェックポイントの設定が遅延される。本発明のチェックポイント復旧システムにより、ユーザアプリケーションプロセスは、持続性状態のうち指定した部分をチェックポイントから除外することができる。返値引数のような、復旧前プロセス状態の選択された部分を、チェックポイント実行された状態にユーザアプリケーションプロセスを復旧する前に保護して、保護された状態の復旧前の値をチェックポイントの復旧後も保持することが可能である。保持された返値は、復旧コードのセグメントが復旧後に実行されることを可能にするとともに、正常実行モードを復旧モードから区別することも可能にする。 (57) [Summary] The checkpoint restoration system saves a process state including a volatile state and a desired part of a persistent state during a normal execution for a user application process, and thereafter saves the saved state. Restore the state. The delayed checkpoint technique delays the setting of a persistent state checkpoint until there is an inconsistency between the checkpointed volatile state and a portion of the persistent state. The checkpoint recovery system of the present invention allows a user application process to exclude a specified portion of the persistent state from a checkpoint. Protect selected parts of the pre-recovery process state, such as return arguments, before restoring the user application process to a checkpointed state, and restore the protected state's pre-recovery values to the checkpoint. It can be retained after recovery. The retained return value allows the segment of the recovery code to be executed after recovery and also allows the normal execution mode to be distinguished from the recovery mode.

Description

【発明の詳細な説明】持続性状態のチェックポイントおよび復旧システム発明の属する技術分野本発明は、プロセスの状態をチェックポイント実行および復旧するシステムに関し、特に、持続するプロセス状態の遅延チェックポイントを含む、プロセス状態を中断および復旧するシステムに関する。従来の技術ますます、ソフトウェアアプリケーションのユーザは、ソフトウェアがソフトウェア故障（フォルト）を起こしにくいこと、あるいは少なくとも故障に対して耐性があることを要求している。例えば、通信交換システムのユーザは、交換システムが連続して利用可能であることを要求する。さらに、通信が、銀行の自動預払機の場合のような金融取引の場合、あるいはその他の重要なデータの場合、顧客は最高度のデータ整合性をも要求する。こうして、ユーザアプリケーションプロセスに結果を引き起こす可能性のある多くのプログラミングエラーを検出するためのさまざまなソフトウェア検査デバッグツールが開発されている。例えば、米国カリフォルニア州SunnyvaleのPure Software，Inc.から市販されており、米国特許第５，１９３，１８０号に記載されている、Purify^TMソフトウェア検査ツールは、メモリアクセスエラーおよびメモリリークを検出するシステムを提供している。Purify^TMシステムは、メモリの各バイトのアロケーションおよび初期化ステータスをモニタする。さらに、メモリにアクセスする各ソフトウェア命令ごとに、Purify^TMシステムはテストを実行し、プログラムが未割当てメモリに書き込みをしていないこと、および、未初期化あるいは未割当てのメモリから読み出しをしていないことを保証する。 Purify^TMシステムのようなソフトウェア検査デバッグツールは、ユーザアプリケーションプロセスにおける故障につながる可能性のある多くのプログラミングエラーを検出するための有効な基礎を提供するが、ソフトウェアデバッグプロセス中に確認、検証あるいは検査をいくら実行しても、すべてのソフトウェア故障を検出して除去し、ユーザアプリケーションプログラムにおける完全な信頼性を与えることはできない。従って、未検査の境界条件による残留故障、予測しない例外、および、予期しない実行環境が、検査およびでバッグのプロセスを免れることが観察されており、プログラム実行中にトリガされるとこれらは表面化して、アプリケーションプロセスのクラッシュあるいはハングを引き起こすことにより、サービス中断を引き起こすことになる。従って、ユーザアプリケーションが、損失する情報の量を最小にして、故障から回復することができる機構を提供することが所望される。そこで、ハードウェアおよびソフトウェアの障害から効果的に回復して、損失する情報量を最小にするために、いくつかのチェックポイント実行および復旧の方法が提案されている。チェックポイント実行およびロールバック（後退復帰）回復の技術に関して一般的には、R．Koo and S．Toueg，″Checkpointing and Rollback-Recovery for Distributed Systems″，IEEE Trans．Software Eng.，Vol.SE-13，No.1，pp.2 3-31（１９８７年１月）に記載されている。一般に、チェックポイントおよび復旧の技術は、正常実行中にプロセスの状態を定期的に保存し、その後、障害後に、保存した状態を復旧する。このようにして、損失する作業の量は、復旧したチェックポイント以降にユーザアプリケーションによってなされた進展へと最小化される。注意すべき点であるが、プロセスの状態には、揮発性の状態と、持続性の状態が含まれる。揮発性状態には、障害があると通常は失われてしまうプロセス情報が含まれる。持続性状態には、ユーザアプリケーションプロセスの現在の実行に関連するすべてのユーザファイルが含まれる。持続性状態は一般に障害があっても失われないが、データ整合性を維持するために、復旧した揮発性状態と同じポイントに、持続性状態を復旧する必要がある。既存のチェックポイント実行および復旧の技術は、揮発性状態のチェックポイント実行には十分に対処しているが、これらの方法は、持続性状態のチェックポイント実行には十分に対処していない。１つのアプローチによれば、すべての持続性状態、換言すれば、すべてのユーザファイルは、揮発性状態の各チェックポイントでチェックポイント実行される。明らかに、この方法に伴うオーバーヘッドは、ほとんどのアプリケーションで非常に大きくなる。既存のUnix^TMのチェックポイントライブラリのような別の方法は、揮発性状態のチェックポイントがとられるときにアクティブあるいはオープンしているユーザファイルのファイルディスクリプタのみをチェックポイント実行する。しかし、この方法では、チェックポイントがとられた後にユーザファイルが作成されあるいはアクティブになった場合、整合性の問題に遭遇する。その理由は、プロセスが最後のチェックポイントに復旧される場合、最後のチェックポイント以降に新たに作成されあるいはアクティブにされたファイルに対する変更はもとに戻されないためである。このような不整合状態は、検出されない破損ファイルを生じることがしばしば起こり得る。このようなチェックポイント実行および復旧の技術は多くのアプリケーション環境で有効に機能するが、いくつかの制限がある。これらの制限は、克服されれば、チェックポイント実行システムの整合性および透明性を拡大するとともに、これまで考えられなかった他のアプリケーションへの有用性も拡大する。特に、ほとんどの従来のチェックポイント実行および復旧の技術は、障害回復に関すること以外のチェックポイント実行および回復の利点を活用していない。上記の説明から明らかなように、持続性状態全体、あるいはその必要な部分が、各チェックポイントに含まれることを可能にするチェックポイント実行および復旧の技術が必要とされている。さらに、不整合が生じるまで持続性状態のチェックポイント実行を遅延させる遅延チェックポイント実行および復旧の技術が必要とされている。さらに、新しいタスクを実行するための開始点として、保存された中間状態を使用することができるように、持続性状態のうちの選択した部分を、与えられたチェックポイントから除外することも可能な、チェックポイント実行および復旧のシステムが必要とされている。さらに、保護された状態の復旧前の値がチェックポイントの復旧後に維持されるように、復旧前に、現在のプロセス状態のうちの選択した部分を保護することが可能なチェックポイントおよび復旧のシステムが必要とされている。発明の概要一般に、本発明の１つの特徴によれば、チェックポイントおよび復旧のシステムは、正常実行中にプロセス状態を保存し、その後で、例えば障害後の回復モード中に、保存された状態を復旧するために、ユーザアプリケーションプロセスにおいてチェックポイントおよび復旧の技術を実装する。本発明の特徴によれば、チェックポイントおよび復旧のシステムは、揮発性および持続性の両方の状態のチェックポイントを実行する。一実施例では、持続性状態のチェックポイント実行は、チェックポイント実行された揮発性状態と、ユーザファイルの間の不整合が生じるまで、持続性状態のチェックポイントをとることを遅延させる遅延チェックポイント法からなる。本発明のもう１つの特徴によれば、チェックポイントおよび復旧のシステムにより、ユーザあるいはユーザアプリケーションプロセスは、持続性状態のうちの選択した部分を、チェックポイントから除外すべきであるとして指定することができる。このようにして、所望の中間状態をチェックポイント実行して、新たな処理タスクを実行するための開始点として使用することができる。例えば、ユーザアプリケーションプロセスが長い初期化プロセスを必要とし、その後、同じ初期化された状態を利用していくつかの入力を処理する場合、入力ファイルをチェックポイントから除外し、初期化された状態をチェックポイント実行することができる。その後、チェックポイント実行された初期化状態を復旧して、新たな入力ファイルのセットごとに、処理タスクを実行することができる。こうして、ユーザアプリケーションプロセスは、所望のあるいは予測可能な状態から、将来の入力を処理することができる。別の実施例では、本発明のチェックポイントおよび復旧のシステムは、持続性状態全体、換言すれば、すべてのユーザファイルを、チェックポイント実行されるプロセス状態の部分がら除外するために利用することが可能である。本発明のもう１つの特徴によれば、コンピュータシステム上で実行されるユーザアプリケーションプロセスをチェックポイント実行し復旧する方法が実現される。この方法において、ユーザアプリケーションプロセスは、揮発性状態と、ユーザファイルからなる持続性状態とを含むプロセス状態を有する。本発明の方法は、チェックポイント位置で揮発性状態をチェックポイント実行するステップと、持続性状態をモニタして、持続性状態を変更することになるチェックポイント位置の後のファイル操作を検出するモニタステップと、モニタステップが、持続性状態の変更が実行されることを検出した場合、持続性状態のうち少なくとも変更されることになる部分をチェックポイント実行するステップと、プロセス状態をチェックポイント位置に復旧することにより、チェックポイント位置以降の持続性状態に対する変更をもとに戻すステップと、チェックポイント位置からユーザアプリケーションプロセスの実行を再開するステップとからなる。本発明のさらにもう１つの特徴によれば、ユーザアプリケーションプロセスに伴う初期化された状態を復旧する方法が実現される。この方法において、ユーザアプリケーションプロセスは、プロセス状態を有し、少なくとも２セットの入力ファイルに対する初期化状態に基づいて処理タスクを実行する。本発明の方法は、（ａ）ユーザアプリケーションプロセスを初期化して初期化状態を形成するステップと、（ｂ）プロセス状態のチェックポイントから除外すべき入力ファイルを指定するステップと、（ｃ）プロセス状態のうち除外されなかった部分をチェックポイント実行するステップと、（ｄ）初期化状態および現在の入力ファイルのセットに基づいて処理タスクを実行するステップと、（ｅ）チェックポイント実行された状態にユーザアプリケーションプロセスを復旧し、復旧モードを示すあらかじめ定義された返値を生成する復旧ステップと、（ｆ）復旧ステップがあらかじめ定義された返値を返した場合、新たな入力ファイルのセットを取得して、除外された入力ファイルを置き換えるステップと、（ｇ）処理すべき入力ファイルのセットごとに、ステップｄ〜ｆを繰り返すステップとからなる。本発明のさらに完全な理解は、本発明のさらに多くの特徴および利点についての理解とともに、詳細な説明および図面を参照して得られる。図面の簡単な説明図１は、本発明によるチェックポイント実行および復旧のシステムを示す概略ブロック図である。図２は、ユーザアプリケーションプロセスの実行グラフであり、揮発性チェックポイント、持続性チェックポイントおよび代替マシンへのプロセスマイグレーションを示す。図３は、ユーザアプリケーションプロセスとオペレーティングシステムの間のファイルシステムコールをモニタして、持続性状態と揮発性状態の間の不整合を生じることになる持続性状態に対する変更を検出する割込みルーチンを示す。図４は、最後の揮発性チェックポイント以降に変更されたファイルごとに持続性状態のチェックポイント情報を保持する持続性チェックポイントテーブルを示す。図５は、ユーザアプリケーションプロセスの実行前に呼び出される例示的な実行前チェックポイントサブルーチンを記述する流れ図である。図６は、揮発性状態をチェックポイント実行するために呼び出される例示的な揮発性状態チェックポイントサブルーチンを記述する流れ図である。図７は、図３のファイルシステムコール割込みサブルーチンの例示的な実装を記述する流れ図である。これは、変更が揮発性状態と持続性状態の間の不整合を生じる前にユーザファイルをチェックポイント実行するために呼び出される。図８Ａおよび図８Ｂは、まとめて、復旧後の処理を制御することが可能な返値とともに、指定されたチェックポイントにプロセス状態を復旧するために利用される例示的な復旧サブルーチンを記述する流れ図である。図９は、ユーザアプリケーションプロセスの実行後に呼び出されることが可能な例示的なクリーンアップサブルーチンを記述する流れ図である。図１０は、リソース不足状態によって引き起こされるソフトウェアの途中終了を迂回するために、本発明の機能を組み込んだサンプルソースコードを示す。図１１は、追加の入力ファイルおよびパラメータのセットの初期化状態をチェックポイント実行しその初期化状態にプロセス状態を復旧するために、本発明の機能を組み込んだ、長い初期化を迂回する例示的なルーチンを記述する流れ図である。図１２は、クリーンなメモリ状態をチェックポイント実行し、そのクリーンなメモリ状態にプロセス状態を復旧するために、本発明の機能を組み込んだ、例示的なメモリ再設定サブルーチンを記述する流れ図である。詳細な説明本発明によるチェックポイント復旧システム１０を図１に示す。以下でさらに説明するように、チェックポイント復旧システム１０によれば、正常実行中にプロセス状態を保存し、その後で、例えば障害後の回復モード中に、保存された状態を復旧するために、ユーザアプリケーションプロセスにおいてチェックポイントおよび復旧の技術を実装することが可能となる。このようにして、アプリケーションプロセスによって失われる作業量は、最後のチェックポイント以降に生成されたものに限定される。システムアーキテクチャ図１に示すように、ここに開示するチェックポイント復旧システム１０は、ミニコンピュータ、ワークステーションまたはその他の汎用コンピュータ装置のような処理ノード２０上に実装することが可能である。処理ノード２０は、少なくとも１つの処理ユニット２５およびメモリ記憶デバイス３０を有する。処理ノード２０の処理ユニット２５およびメモリ記憶デバイス３０は、既知のように、バス６０によって、または、ノード内通信のためのローカル処理ノード２０上のプロセス間通信（ＩＰＣ）設備によって、相互接続されることが可能である。さらに、各ノード２０は、既知のように、シリアルまたはパラレルのノード間通信のための通信リンク７５へのネットワークインタフェース７０によって、他のノードあるいはリモート集中回復コーディネータ（図示せず）と相互接続されることも可能である。ネットワークインタフェース７０は、例えば、米国ペンシルヴェニア州ピッツバーグのFore Systems，Inc.から市販されているＡＴＭホストアダプタカードである。このようにして、ユーザアプリケーションプロセスが、例えば永久的なあるいは長期間のハードウェア障害により、ローカルノード２０上で回復することができない場合、ユーザアプリケーションプロセスは、リモートの処理ノードにエクスポートされることが可能である。この技術はしばしばプロセスマイグレーションと呼ばれる。処理ユニット２５は、単一のプロセッサとして、あるいは、並列に動作するいくつかのプロセッサとして実現することが可能である。メモリ記憶デバイス３０は、一般に不安定な揮発性メモリの領域であるが、処理ユニット２５が取得、解釈および実行することが可能な命令を格納することができる。一実施例では、揮発性メモリ記憶デバイス３０は、処理ユニット２５によって実行されるプロセス４０のような各ユーザアプリケーションプロセスに関連するソフトウェアコードとともに、ユーザプロセス４０によって呼び出されるチェックポイントライブラリ関数５０を格納する。さらに、揮発性メモリ記憶デバイス３０は、既知のように、ユーザアプリケーションプロセス４０、および、チェックポイント復旧ライブラリ関数５０のそれぞれに関連するデータを記憶するデータセグメントセクション５５を含む。ユーザアプリケーションプロセス４０によって呼び出されるチェックポイントライブラリ関数５０は、チェックポイント復旧ライブラリ１５０から選択される。チェックポイント復旧ライブラリ１５０は、ローカルに格納することも可能であり、あるいは、ファイルシステム１２０のように集中ファイルシステム上に格納することも可能である。ファイルシステム１２０のようなファイルシステムは、ユーザがアクセス可能なファイルを格納するための集中倉庫を提供する。一般に、集中ファイルシステム１２０は、不揮発性すなわち持続性メモリの領域であり、電源がなくても情報を保持することができる。以下でさらに説明するように、チェックポイント復旧ライブラリ１５０に含まれる関数は、Ｃプログラミング言語のような高水準プログラミング言語で書かれたユーザレベルのライブラリ関数である。チェックポイント復旧ライブラリ１５０内の関数は、正常実行中にプロセス状態を保存するために、あるいは、例えば障害後の回復モード中に、保存された状態を復旧するために、ユーザアプリケーションプロセスが読み出すことができる。一実施例では、チェックポイント復旧ライブラリ１５０から関数を呼び出すユーザプロセス４０はは、コンパイル中に、あるいは、ダイナミックリンキングプロセスによって、呼び出される関数のコードとバインドされる。図１に示すように、チェックポイント復旧ライブラリ１５０は、実行前チェックポイントサブルーチン１５２を有する。実行前チェックポイントサブルーチン１５２はユーザアプリケーションプロセスの実行前に呼び出される。実行前チェックポイントサブルーチン１５２についてさらに詳細には図５に関して後述する。さらに、チェックポイント復旧ライブラリ１５０は、揮発性状態チェックポイントサブルーチン１５４を有する。揮発性状態チェックポイントサブルーチン１５４は、ユーザアプリケーションプロセス４０によって呼び出されると、揮発性メモリ３０から、ディスク１００のような不揮発性メモリの領域に、揮発性状態のコピーを格納する。チェックポイントディスク１００は、処理ノード２０上にローカルに存在することも可能であり、あるいは、通信ネットワークのリモートノード上に存在することも可能である。揮発性状態チェックポイントサブルーチン１５４についてさらに詳細には図６に関して後述する。さらに、チェックポイント復旧ライブラリ１５０は、ファイルシステムコール割込みサブルーチン１５６を有する。ファイルシステムコール割込みサブルーチン１５６は、持続性状態の所望の部分をチェックポイント実行するための遅延技術を提供する。ファイルシステムコール割込みサブルーチン１５６についてはさらに図３および図７に関して後述する。また、ライブラリ１５０は、復旧サブルーチン１５８を有する。復旧サブルーチン１５８は、ユーザアプリケーションプロセスを所望のチェックポイントに復旧するために呼び出される。復旧サブルーチン１５８についてはさらに図８Ａおよび図８Ｂに関して後述する。既に指摘したように、復旧サブルーチン１５８は、持続性状態チェックポイントから除外されるユーザファイルをユーザが指定することを可能にする機構を提供して、ユーザアプリケーションプロセスが所望のあるいは予測可能な状態から将来の入力を処理することを可能にする。最後に、チェックポイント復旧ライブラリ１５０は、クリーンアップサブルーチン１６０を有する。クリーンアップサブルーチン１６０は、必要な場合に、作成されたチェックポイントファイルを削除するために、ユーザアプリケーションプロセスの実行後に呼び出される。さまざまな実装において、復旧サブルーチン１５８は、当業者には明らかなように、検出された故障に応じて自動的に開始されることも可能であり、あるいは、例えばコマンドライン入力によって、ユーザによりマニュアルで開始されることも可能である。自動実装では、図１に示すように、ノード２０のような各ノードはウォッチドッグ８０を有することが可能である。ウォッチドッグ８０は、それぞれのノード上で実行されているプロセスをモニタするエラー検出モニタ８５を含む。エラー検出モニタ８５は、プロセスがハングしているかあるいはクラッシュしたかどうかを判定するために、プロセス４０のような、ノード２０上で実行されているアプリケーションプロセスを連続してモニタする。エラー検出モニタ８５によって実行されるモニタリングは、能動的であることも受動的であることも可能である。能動的モニタリング構成では、ウォッチドッグ８０は、ローカルノード２０上のプロセス間通信（ＩＰＣ）設備を用いてプロセスにメッセージを定期的に送り、その返値を評価することによって、モニタされる各アプリケーションプロセスをポーリングしてそのプロセスの状態を判定し、プロセスがまだアクティブであるかどうかを判断する。受動的モニタリング構成では、各アプリケーションプロセスはライブラリ１５０からの関数を含み、この関数は、プロセス４０のようなユーザアプリケーションプロセスによって呼び出されると、指定された間隔で、ウォッチドッグ８０へ、プロセス４０がまだアクティブであることを示すハートビート（鼓動）メッセージを送る。指定された間隔の終了前にウォッチドッグ８０がアプリケーションプロセス４０からシグナルを受信しない場合、ウォッチドッグ８０は、アプリケーションプロセスがハングしているかあるいはクラッシュしたと推定する。後でさらに説明するが、エラー検出モニタ８５によってユーザアプリケーションプロセス４０における故障が検出されると、再開始サブシステム９０が、後述のように、最後のチェックポイントから、故障したアプリケーションプロセスの再開始を行うことによって、故障したアプリケーションプロセスの回復を試みる。再開始サブシステム９０は、障害が検出されたときに復旧サブルーチン１５８を呼び出して、故障したユーザアプリケーションプロセスの再開始を行う。チェックポイントおよび復旧の概念および定義チェックポイントおよび復旧の概念および定義に関する一般的に説明は、例えば、Yi-Min Wang et al.，″Progressive Retry Technique for Software Error Recovery in Distributed Systems″，Proc．of 23rd IEEE Conf．on Fault-To lerant Computing Systems(FTCS)，pp.138-144（１９９３年６月）、あるいは、 R．Koo and S．Toueg，″Checkpointing and Rollback-Recovery for Distribut ed Systems″，IEEE Trans．Software Eng.，Vol.SE-13，No.1，pp.23-31（１９８７年１月）に記載されている。一般に、チェックポイントおよび復旧の技術は、損失する作業の量を最小にするために、正常なプログラム実行中にときどきプロセス状態を保存し、その後、例えば障害後に、保存されている状態を復旧する。図２に、プロセス４０のようなユーザアプリケーションプロセスの実行を示す。ユーザアプリケーションプロセス４０が実行を続ける間に、揮発性チェックポイントＶＣ₁、ＶＣ₂およびＶＣ₃のように、揮発性状態のチェックポイントが呼び出される。ここで、揮発性状態という用語には、プログラムスタック、オープンファイルディスクリプタ、スタティック（静的）およびダイナミック（動的）データセグメントのような、障害時に通常は失われてしまう情報と、オペレーティングシステムレジスタ、プログラムカウンタおよびスタックポインタのような、現在のプログラム実行に本質的なオペレーティングシステムカーネルに関連するデータ構造体が含まれる。さらに、本発明の特徴によれば、ユーザアプリケーションプロセス４０が、ユーザファイルの属性のような、持続性状態を変更するファイル操作を実行しようとする場合、影響されるファイルは、後述のようにして、所望のファイル操作が実行される前に、持続性チェックポイントＰＣ_3'およびＰＣ₃ _″〜によって示されるように、チェックポイント実行される。ここで、持続性状態という用語には、ユーザアプリケーションプロセスの現在の実行に関連するすべてのユーザファイルが含まれる。持続性状態は一般に障害時に失われないが、持続性チェックポイントは、例えば障害が検出されたときにプロセスがその最後の揮発性チェックポイントまでロールバックした場合に、持続性状態が揮発性状態と整合することを保証する。注意すべき点であるが、持続性状態は、与えられたファイルへの更新が、最後のチェックポイントに関連する揮発性状態と不整合になるまでは、記録されない。後述のように、持続性チェックポイントＰＣ_3'およびＰＣ₃ _″によって、最後の揮発性チェックポイント以降の持続性状態へのすべての変更はもとに戻される。このようにして、「Ｆ₁」で示される点で障害が検出されると、プロセスの揮発性状態は、最後の揮発性チェックポイントＶＣ₃に関連するチェックポイントデータを復旧することによって、チェックポイントＶＣ₃までロールバックすることができる。さらに、持続性チェックポイントＰＣ_3'およびＰＣ₃ _″によって、最後の揮発性チェックポイントＶＣ₃以降の持続性状態への変更はそれぞれもとに戻される。こうして、ロールバック後、持続性状態全体は、最後の揮発性チェックポイントＶＣ₃のときに存在したとおり、揮発性状態と整合する。注意すべき点であるが、プロセスがマシンＡで再開始することができない場合、図２に示すように、プロセスマイグレーションによって、プロセスは、マシンＢのような代替マシン上で再開始することが可能である。ファイルシステムコールに割り込むことによる持続性状態のモニタリング既に指摘したように、持続性状態には、ユーザアプリケーションプロセスの現在の実行に関連するすべてのユーザファイルが含まれる。一般に、ユーザアプリケーションプロセスがユーザファイルにアクセスし、それを変更することが可能な唯一の方法は、オペレーティングシステムカーネルに送られるファイルシステムコールによるものである。従って、ユーザアプリケーションプロセスによって生成される各ファイルシステムコールに割り込み、チェックポイント復旧システム１０によって評価すれば、持続性状態への可能なすべての変更を識別することが可能である。こうして、図３に概念的に示したように、プロセス４０のようなユーザアプリケーションプロセスによって生成されるすべてのファイルシステムコールは、所望のファイル操作が実際にオペレーティングシステム３００によって実行される前に、割込みルーチン１５６によって割り込まれモニタされる。これについては図７に関して後述する。このようにして、ファイル操作が持続性状態に関連するファイルを変更しようとしている場合、影響されるファイルの情態は整合性を保証するために記録することができる。一実施例では、持続性状態チェックポイントは、図４に示す持続性チェックポイントテーブル４００に記録される。持続性チェックポイントテーブル４００は、ディスクのような持続性メモリに格納され、テーブル４００が変更されるごとにディスクに格納される。各持続性チェックポイントテーブル４００は、特定のユーザアプリケーションプロセスに関連するとともに、checkpoint idによって識別される特定の揮発性チェックポイントに関連し、行４０５および４１０のような複数の行を有する。各行は、関連する揮発性チェックポイント以降に何らかの変更を受けたユーザファイルに対応する。「ファイル名」によって示される各ファイルごとに、持続性チェックポイントテーブル４００は、変更される可能性のある各ファイル属性ごとのエントリを有する。例えば、持続性チェックポイントテーブル４００は、各ファイルの「変更時刻」を記録するための列４３５と、各ファイルの「アクセスモード」を記録するための列４４０と、各ファイルの現在の「サイズ」を記録するための列４４５を含む。一実施例では、テーブル４００の各エントリは、与えられたファイルに対して行が作成されるときに、「−１」のようなデフォルト値で初期化される。その後、ファイルの属性が変更されると、現在の属性値を、変更前に記録することができる。このようにして、復旧されるファイルの与えられた属性が「−１」という値である場合、その属性は変更されておらず、復旧の必要がない。図７に関して後述するように、エントリは、ファイルシステムコール割込みサブルーチン１５６によって、持続性チェックポイントテーブル４００内に作成される。さらに、図８Ａおよび図８Ｂに関して後述するように、checkpoint idの値によって識別される特定のチェックポイントの復旧中に、復旧サブルーチン１５８は持続性チェックポイントテーブル４００にアクセスし、それに含まれる情報を利用して持続性状態を復旧する。チェックポイント復旧ライブラリ関数実行前チェックポイントサブルーチン既に指摘したように、チェックポイント復旧ライブラリ１５０は、実行前チェックポイントサブルーチン１５２を含む。実行前チェックポイントサブルーチン１５２は、ユーザアプリケーションプロセス４０の実行前に実行される。例えば、Ｃプログラミング言語で書かれたプログラムは、通常、″main″ルーチンを有する最初の行から実行を開始する。従って、実行前チェックポイントサブルーチン１５２の実行は、″main″ルーチンの実行前に呼び出されるべきである。チェックポイント復旧システム１０は、挿入モードと透過モードという、チェックポイントを実行するための２つの動作モードを提供する。挿入モードは、ソースコードの所望の位置にチェックポイント関数を挿入することによって、ユーザアプリケーションプロセスがチェックポイント機構を実装することを可能にする。透過モードは、指定された時間間隔で自動的にチェックポイントを実行する機構を提供する。透過モードによれば、ユーザアプリケーションプロセスは、ユーザアプリケーションプロセスへの変更や再コンパイルを必要とすることなく、チェックポイント機構を組み込むことが可能となる。後述のように、透過モードでは、あらかじめ定義された間隔でチェックポイントを開始するために、実行前チェックポイントサブルーチン１５２によってクロックデーモンプロセスが生成される。後述のように、それぞれの指定された間隔の終了時に、チェックポイントを開始するために、生成されたクロックデーモンプロセスの指示により、システム割込みコールがオペレーティングシステムによって関連するユーザアプリケーションプロセスに送信される。図５に示すように、実行前チェックポイントサブルーチン１５２は、ステップ５００から開始し、その後、ステップ５０５で、チェックポイント復旧システム１０によって要求される、オープンファイルテーブルおよび持続性チェックポイントテーブル４００のようなデータ構造体を初期化する。その後、ステップ５２０で、例えばコマンドライン上のユーザによる指定から、あるいは、環境変数の設定から、ユーザアプリケーションプロセスが挿入モードで実行されているかそれとも透過モードで実行されているかを判定するテストを実行する。ステップ５２０で、ユーザアプリケーションプロセスが透過モードで実行されていると判定された場合、ステップ５２５で、例えばforkシステムコールによって、クロックデーモンプロセスが生成される。既に指摘したように、クロックデーモンプロセスは、指定された間隔でユーザアプリケーションプロセスのチェックポイントを開始するチェックポイントタイマとして作用する。一実施例では、チェックポイントは、谷間隔が指定されていなければ、３０分ごとのようなデフォルト間隔で開始される。一方、ステップ５２０で、ユーザアプリケーションプロセスが挿入モードで実行されていると判定された場合は、ユーザアプリケーションプロセスの実行によって呼び出されるときにのみチェックポイントは開始される。ステップ５４０で、ユーザアプリケーションプロセスに対する正しいチェックポイントファイルが既に存在するかどうかを判定するテストが実行される。換言すれば、このテストは、現在の実行が通常実行モードであるかそれとも回復モードであるかを判定する。注意すべき点であるが、ユーザアプリケーションプロセスが正常終了すると、特に指定しない限り、図９に関して後述するように、クリーンアップサブルーチン１６０が、そのユーザアプリケーションプロセスに関連するチェックポイントファイルを削除する。こうして、ユーザアプリケーションプロセスの開始時にチェックポイントファイルが存在する場合、例えば障害により前の実行が正常終了しなかったか、あるいは、ユーザアプリケーションプロセスが、後の復旧のためにチェックポイントファイルを格納するよう要求したかのいずれかである。ステップ５４０で、ユーザアプリケーションプロセスに対する正しいチェックポイントファイルが存在すると判定された場合、実行前チェックポイントサブルーチン１５２は復帰し、図８Ａおよび図８Ｂに関して後述するように、存在するチェックポイントファイルに関連するデータを復旧し、復旧したチェックポイントの時点からユーザアプリケーションプロセスの実行を開始するために、ステップ５５０で、復旧サブルーチン１５８の実行が開始される。一方、ステップ５４０で、ユーザアプリケーションプロセスに対する正しいチェックポイントファイルが存在しないと判定された場合、実行前チェックポイントサブルーチン１５２は復帰し、ステップ５６０で、ユーザアプリケーションプロセスの実行が開始される。揮発性状態チェックポイントサブルーチン既に指摘したように、チェックポイント復旧ライブラリ１５０は、揮発性状態チェックポイントサブルーチン１５４を有する。揮発性状態チェックポイントサブルーチン１５４は、透過モードでは、チェックポイントを開始すべきであるというクロックデーモンからの割込みシグナルによって、あるいは、挿入モードでは、ユーザアプリケーションプロセスのソースコードに挿入されたチェックポイント関数コールが実行されるときに、呼び出される。さらに、後述のように、揮発性状態チェックポイントサブルーチン１５４は、プログラムカウンタの値が復旧された後に間接的に復旧サブルーチン１５８から呼び出される。揮発性状態チェックポイントサブルーチン１５４は、ユーザアプリケーションプロセスを復旧するために必要な、障害時に失われてしまうすべての情報を保存する。一実施例では、揮発性状態チェックポイントサブルーチン１５４は、各チェックポイント間隔を識別するために利用可能なcheckpoint id引数を渡される。揮発性状態チェックポイントサブルーチン１５４がcheckpoint id引数を渡されない場合、以前のチェックポイントデータが上書きされる。checkpoint id引数はグローバル変数とすることにより、後で、持続性状態のチェックポイントを実装するファイルシステムコール割込みサブルーチン１５６が、適当な（現在の）揮発性チェックポイントに持続性状態チェックポイントを関連づけるために、アクセスすることができる。既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザアプリケーションプロセスの現在の実行に関連するいくつかの揮発性情報は、オペレーティングシステムカーネルによって管理される。これらのメモリ要素は通常はユーザアプリケーションプロセスによってアクセス可能ではないが、オペレーティングシステムは一般に、特定のユーザアプリケーションプロセスによって要求されるオペレーティングシステム情報をチェックポイント実行することを可能にするルーチンを提供している。このタスクを実行するためにオペレーティングシステムによって提供されるルーチンは、ステップ６１０で、レジスタ、スタックポインタおよびプログラムカウンタの内容を保存するために実行される。例えば、Unixオペレーティングシステムは、これらのオペレーティングシステムデータ構造体にアクセスし、宣言したグローバルデータ構造体にそれらを保存するse tjmpコールを提供している。それらのグローバルデータ構造体は、その後、揮発性状態の一部としてチェックポイント実行することができる。setjmpシステムコールの動作の詳細については、例えば、W．R．Stevens，″Advanced Programmin g in the Unix Environment″，pp.174-180(Addison Wesley，1992)に記載されている。その後、プログラム制御はステップ６２０に進む。注意すべき点であるが、復旧サブルーチン１５８（図８Ａおよび図８Ｂ）の実行中、所望のチェックポイントの復旧後、プログラムカウンタの値は、復旧したチェックポイントに対応する値に復旧される。従って、プログラムカウンタの値が変更されることにより、復旧サブルーチン１５８は、ステップ６１０の実行の直後の位置にジャンプすることになる。さらに注意すべき点であるが、復旧サブルーチン１５８は、０より大きい返値を返す。これは、復旧後の実行のフローを制御するために利用可能である。例えば、あるあらかじめ定義された返値の場合にはあるコードが実行され、別のあらかじめ定義された返値の場合には別のコードのシーケンスが実行される。こうして、ステップ６２０で、setjmpシステムコールのようなオペレーティングシステムルーチンからの返値が０という値であるかどうかを判定するテストが実行される。既に指摘したように、復旧サブルーチン１５８により、０より大きい返値を、回復モードで利用することが可能である。ステップ６２０で、返値が０でないと判定された場合、揮発性状態チェックポイントサブルーチン１５４の現在の実行が、回復モードで復旧サブルーチン１５８から呼び出されており、プログラム制御は、チェックポイント実行を行うことなく直接ステップ６７０に進む。一方、ステップ６２０で、返値が０に等しいと判定された場合、揮発性状態チェックポイントサブルーチン１５４の現在の実行は復旧サブルーチン１５８から呼び出されたものではなく、揮発性状態チェックポイントサブルーチン１５４は揮発性チェックポイントを続ける。すなわち、ステップ６３０で、揮発性チェックポイントの時点でオープンしているすべてのファイルのファイルディスクリプタが、そのファイルのファイル名および現在の位置とともに、オープンファイルテーブルに格納される。オープンファイルテーブルは、各オープンファイルのファイルディスクリプタ、ファイル名および位置を含む。その後、ステップ６４０で、ユーザアプリケーションプロセスに関連するデータセグメントが、グローバル変数およびスタティック変数のようなすべての動的および静的に割り当てられたメモリと、オープンファイルテーブルを含めて、保存される。最後に、ステップ６５０で、スタックの現在の内容が保存される。揮発性状態チェックポイントサブルーチン１５４の実行はステップ６７０で終了し、その後、指示された返値とともに復帰する。揮発性状態チェックポイントサブルーチン１５４が０の値を返す場合、これは、チェックポイントをとることに成功したことを示す。さらに、揮発性状態チェックポイントサブルーチン１５４が０より大きい値を返す場合、これは、実行のフローを制御するために利用可能な返値とともに復旧サブルーチン１５８から間接的に実行が復帰していることを示す。ファイルシステムコール割込みサブルーチン既に指摘したように、チェックポイント復旧ライブラリ１５０は、持続性状態チェックポイントを実装するファイルシステムコール割込みサブルーチン１５６を含む。ファイルシステムコール割込みサブルーチン１５６は、ファイルの特定の属性を変更する可能性のあるファイルシステムコールに割り込み、必要な場合には、持続性状態のうちの変更される部分の遅延チェックポイントを実行する。ファイルシステムコール割込みサブルーチン１５６は、要求されるファイル操作を実際に実行する前に、持続性状態チェックポイントを実行する。さらに、ファイルシステムコール割込みサブルーチン１５６は、必要な限りにおいてのみ、持続性状態のチェックポイントを実行する。ファイルシステムコール割込みサブルーチン１５６は、それぞれの割り込まれるファイルシステムコールの受信時に、ステップ７００から開始する。ステップ７１０で、割り込まれるファイル操作が、チェックポイントの設定を開始すべきファイル属性を変更するかどうがを判定するテストが実行される。ステップ７１０で、割り込まれるファイル操作がチェックポイントの設定を開始すべきファイル属性を変更しないと判定された場合、プログラム制御はステップ７５０に進み、後述のようにして所望のファイル操作を実行する。一方、ステップ７１０で、割り込まれるファイル操作がチェックポイントの設定を開始すべきファイル属性を変更すると判定された場合、ステップ７２０で、ユーザが例えば関数コールを実行すること、コマンドライン引数を入力すること、あるいは環境変数を設定することによって、現在のファイルはチェックポイントから除外すべきであると指定したかどうかを判定するテストが実行される。このようにして、ユーザあるいはユーザアプリケーションプロセスは、与えられたファイルが持続性状態チェックポイントに含まれるべきがどうかを、ファイルごとに選択的に指定することができる。ステップ７２０で、現在のファイルはチェックポイントから除外すべきであると判定された場合、プログラム制御はステップ７５０に進み、後述のようにして所望のファイル操作を実行する。一方、ステップ７２０で、現在のファイルはチェックポイントから除外すべきでないと判定された場合、ステップ７３０で、グローバル変数checkpoint idの現在の値によって識別される最後の揮発性チェックポイント以降にこのファイルは既にチェックポイント実行されたかどうかを判定するテストが実行される。ステップ７３０で、最後の揮発性チェックポイント以降にこのファイルは既にチェックポイント実行されたと判定された場合、プログラム制御はステップ７５０に進み、後述のようにして所望のファイル操作を実行する。一方、ステップ７３０で、最後の揮発性チェックポイント以降にこのファイルは既にチェックポイント実行されてはいないと判定された場合、ステップ７４０で、このファイルのシャドウコピーを作成し、ファイル名と、変更される属性の以前の値を、checkpoint idの現在の値に対応する持続性チェックポイントテーブル４００に追加することによって、このファイルはチェックポイント実行される。代替実施例では、持続性状態チェックポイントは、属性ごとに各ファイルをチェックポイント実行し、現在のファイルシステムコールによって影響される属性のみをチェックポイント実行することによって、さらに最適化することが可能である。換言すれば、ファイル操作は全属性のうちのサブセットのみに影響し、ファイル操作がステップ７５０で実行される前に、影響される属性のサブセットのみをチェックポイント実行すればよい。例えば、writeシステムコールが既存のファイルの終端にデータを追加するのみである場合、そのファイルの、揮発性チェックポイントにおいて存在したファイル内容は変更されないため、ファイル内容をチェックポイント実行せず、ファイルサイズをチェックポイント実行すれば十分である。復旧後、このファイルは適当なサイズに切り詰めることが可能である。ステップ７４０でファイルをチェックポイント実行した後、必要であれば、ステップ７５０で、所望のファイル操作を実行することが可能である。持続性状態チェックポイントは、ファイル操作が実行される前に記録されるため、持続性チェックポイントテーブル４００に格納される情報は、最後の揮発性チェックポイント以降に各ユーザファイルになされた変更をもとに戻すために使用することが可能である。ステップ７５０で、所望のファイル操作が実行された後、ファイルシステムコール割込みサブルーチン１５６の実行はステップ７６０で終了し、ユーザアプリケーションプロセスの実行に復帰する。復旧サブルーチン既に指摘したように、チェックポイント復旧ライブラリ１５０は、図８Ａおよび図８Ｂに示す復旧サブルーチン１５８を含む。復旧サブルーチン１５８は、例えば障害が検出された後にウォッチドッグ８０によってアプリケーションプロセスが正しいチェックポイントから再開始されるときに、あるいは、ユーザアプリケーションプロセスに対応するソースコードにロールバック関数コールが挿入されているときに、呼び出される。ここで、ロールバックという用語は、ユーザあるいはユーザアプリケーションプロセスによって開始される復旧を示し、回復という用語は、正しいチェックポイントファイルによる障害後の復旧を示すために用いられる。一実施例では、復旧サブルーチン１５８には以下の引数が渡される。・mode（モード）の値は、現在の実行が回復モードであるかそれともロールバックモードであるかを示す。・checkpoint id（チェックポイントＩＤ）の値およびreturn value（返値）は保持され復旧サブルーチン１５８の実行後に返される。・protected variables（保護変数）のリストは、プロセスがチェックポイントに復旧された後であっても、復旧前の値を維持する。注意すべき点であるが、checkpoint idの値が指定されない場合、プロセスは最後のチェックポイントに復旧される。さらに、return valueが指定されない場合、正の返値（例えば１）が用いられる。復旧サブルーチン１５８は、指示されるチェックポイントに対応する揮発性および持続性の状態を復旧するように作用する。後述のように、復旧サブルーチン１５８は、揮発性チェックポイントを復旧し、復旧した揮発性チェックポイント以降に持続性状態になされた変更をもとに戻すことによって、揮発性状態と持続性状態の間の整合性を保証する。本発明の特徴によれば、復旧サブルーチン１５８がユーザアプリケーションプロセスによって呼び出されるときに、return valueおよびprotected variables 配列が指定される。一実施例では、復旧サブルーチン１５８が指示されたチェックポイントにロールバックするときには、protected variables配列によって指示される変数の現在の値が、return value変数の現在の値とともに、保護される。こうして、特定のチェックポイントへの復旧後、復旧の前に指定されたreturn valueが維持され、復旧後の実行のフローを制御するために利用することが可能である。さらに、ユーザあるいはユーザアプリケーションプロセスがすべての変数を特定のチェックポイントにロールバックすることを望まない場合、protecte d variablesの機構を利用して、復旧後にも現在の値を維持すべき変数を指定することができる。return valueが指定されない場合、デフォルト値として１が用いられる。図８Ａに示すように、呼び出されると、復旧サブルーチン１５８はステップ８００から開始される。その後、ステップ８１０で、checkpoint id引数で指示される値に対応する持続性チェックポイントテーブル４００（図４）が読み出される。ステップ８１５で、ユーザが、例えばコマンドライン入力によってあるいは環境変数の設定によって、持続性チェックポイントテーブル４００にリストされたシャドウファイルを復旧してはならないことを示すように、持続性チェックポイントテーブル４００が変更されるべきことを指示したかどうかを判定するテストが実行される。ステップ８１５でユーザが持続性チェックポイントテーブル４００を変更すべきであることを指示したと判定された場合、ステップ８２０で、テーブル４００は、指示された変更に従って変更される。持続性チェックポイントテーブル４００が変更された後、必要であれば、ステップ８２５で、テーブル４００にリストされた各ファイルに対応するシャドウファイルを適当なチェックポイントデータから検索し、そのシャドウファイルを現在のファイル上にコピーすることによって、持続性チェックポイントテーブル４００に従って持続性状態が復旧される。さらに、持続性チェックポイントテーブル４００にリストされた各ファイルの属性が、テーブル４００内のそれぞれのエントリに記録された値に従って変更される。その後、ステップ８３０で、復旧サブルーチン１５８の現在の実行モードが、障害後の回復モードであるか、それとも、ユーザが開始したロールバックモードであるか、および、protected variables配列の値が正しいかどうかを判定するテストが実行される。ステップ８３０で、復旧サブルーチン１５８の現在の実行モードがロールバックモードであり、protected variables配列の値が正しいと判定された場合、ステップ８３５で、チェックポイント実行されるデータセグメントが復旧される間にprotected variables配列によって指定された変数を保護するために、これらの変数がデータセグメントから一時ファイルにコピーされる。その後、ステップ８４０で、checkpoint id引数によって識別される揮発性チェックポイントファイルが読み出される。ステップ８４５で、前のステップで取得した揮発性チェックポイントファイルを用いて、オープンファイルテーブルを含むデータセグメントが復旧される。その後、ステップ８５０で、復旧サブルーチン１５８の現在の実行モードがロールバックモードであるかどうか、および、protected variables配列の値が正しいかどうかを判定するテストが再び実行される。ステップ８５０で、復旧サブルーチン１５８の現在の実行モードがロールバックモードであり、protected va riables配列の値が正しいと判定された場合、ステップ８５５で、 protected variables配列によって指定された変数は、一時ファイル内の保護された位置からデータセグメントにコピーされて戻される。このようにして、prot ected variables配列で指定される各変数は復旧前の値を維持する。ステップ８６５で、ユーザが、例えばコマンドライン入力によってあるいは環境変数の設定によって、オープンファイルテーブルを変更すべきであると指示したかどうかを判定するテストが実行される。ステップ８６５で、ユーザが、オープンファイルを変更すべきであると指示したと判定された場合、指示された変更がステップ８７０で実行される。例えば、後で「長い初期化の迂回」と題する節で説明する、本発明の特徴を含む１つのアプリケーションでは、復旧されるオープンファイルテーブルは、以前に処理された入力ファイルの第１のセットをリストする。処理すべき入力の後続の各セットごとに、入力ファイルの第１のセットを、現在の実行に適した入力ファイルのセットで置き換えるために、オープンファイルテーブルを変更する。オープンファイルテーブルが変更された後、必要であれば、ステップ８７５で、オープンファイルテーブルに指示されるファイルディスクリプタが復旧される。換言すれば、オープンファイルテーブル内の各エントリごとに、ファイルがオープンされ、ファイル名は指示されたファイルディスクリプタに関連づけられ、ファイルの現在位置がオープンファイルテーブルエントリに記録された位置に調整される。その後、ステップ８８０で、スタックスペースが割り当てられ、ステップ８８５で、スタックが、ステップ８４０で読み出された揮発性チェックポイントファイル内の情報に従って復旧される。既に指摘したように、中央処理ユニット内での値の一時記憶のためのハードウェアレジスタ、スタックポインタおよびプログラムカウンタのような、ユーザアプリケーションプロセスの実行に関連するいくつかの揮発性情報は、オペレーティングシステムカーネルによって管理される。これらのメモリ要素は通常はユーザアプリケーションプロセスによってアクセス可能ではないが、オペレーティングシステムは一般に、特定のユーザアプリケーションプロセスによって要求されるオペレーティングシステム情報を復旧することを可能にするルーチンを提供している。このタスクを実行するためにオペレーティングシステムによって提供されるルーチンは、ステップ８９０で、レジスタ、スタックポインタおよびプログラムカウンタの内容を復旧するために実行される。例えば、Unixオペレーティングシステムは、これらのオペレーティングシステムデータ構造体を復旧するlong jmpコールを提供している。longjmpシステムコールの動作の詳細については、例えば、W．R．Stevensの前掲書に記載されている。既に指摘したように、プログラムカウンタの値が、チェックポイントが復旧されるときに記録された値に復旧されると、復旧サブルーチンの実行は、揮発性状態チェックポイントサブルーチン１５４（図６）のステップ６２０にジャンプする。こうして、復旧サブルーチン１５８は、揮発性状態チェックポイントサブルーチン１５４から効果的に復帰することになる。さらに、復旧サブルーチン１５８は、指示されたreturn valueおよびprotected variables配列に指示された変数を復旧前の値に維持したまま復帰する。クリーンアップサブルーチン既に指摘したように、チェックポイント復旧ライブラリ１５０は、ユーザアプリケーションプロセスの実行後に実行されるクリーンアップサブルーチン１６０を含む。図９に示すように、クリーンアップサブルーチン１６０は、ユーザアプリケーションプロセスが終了したときにステップ９００から開始される。ステップ９１０で、ユーザアプリケーションプロセスの現在の実行モードが透過モードであるかどうかを判定するテストが実行される。ステップ９１０で、現在の実行モードが透過モードであると判定された場合、ステップ９３０で、実行前チェックポイントサブルーチン１５２によって生成されたクロックデーモンプロセスが削除(kill)される。その後、ステップ９５０で、ユーザアプリケーションプロセスに関連するチェックポイントファイルを維持すべきかどうかを判定するテストが実行される。ステップ９５０で、チェックポイントファイルを保持すべきでないと判定された場合、ステップ９７０で、ユーザアプリケーションプロセスに関連するチェックポイントファイルは削除される。ステップ９８０で、クリーンアップサブルーチン１６０は実行を終了する。チェックポイント復旧アプリケーションソフトウェアの途中終了の迂回ユーザアプリケーションプロセスは、実行の継続に必要なリソースを割り当てることができないために途中で終了することがある。ソフトウェア障害とは異なり、プロセスがリソース不足状態あるいは例外状態により途中終了するときは、プロセスは依然として、プログラムが終了する直前の時点での制御下にある。ここで、例外状態とは、ユーザアプリケーションプロセスによって規定される正常な実行フロー以外の実行であると定義される。一般に、プロセスが必要なリソース（例えば動的メモリ）を割り当てることができないときには、プロセスは、「リソース割当て不能」状態を示すエラーメッセージを印字し、プログラムは途中終了する。このようなソフトウェア途中終了は、多くの有用な処理が浪費されるため、特に長時間動作したアプリケーションでは、もちろん好ましくない。一般に、プロセスは、最初から、あるいは、おそらくは、透過チェックポイントモードで指定された間隔で設定された最後のチェックポイントから、再開始しなければならない。しかし、本発明によるチェックポイント復旧システム１０によれば、プロセスが終了する時点の直前で、ソースコードにチェックポイント関数コールを挿入することが可能である。このようにして、プロセス状態は、後で、途中終了に対応する位置の直前の点に復旧することができる。さらに、本発明によれば、ユーザアプリケーションプロセスが最後のチェックポイントに復旧した後の実行制御機能を利用することによって、復旧サブルーチン１５８の返値は、必要であれば、現在の実行が特殊な回復処理を開始する回復モードであることを示すことが可能である。図１０に、例えば動的メモリを割り当てることの障害によって引き起こされたソフトウェア途中終了を迂回するために利用可能な本発明の機能を含むソースコードのセグメントを示す。第１０１５〜１０５０行に示されるコード列は、第１０１０行でプロセスが動的メモリを割り当てることができない限り実行される。第１０１０行で実行されるmalloc関数コールは、通常Ｃプログラミング言語の関数ライブラリにあるメモリ割当て関数であり、要求されたサイズのメモリブロックを割り当て、宣言されたポインタptrに、割り当てたメモリの開始アドレスの値を返す。例えば他のプロセスが残りのスワップスペースを使い尽くしてしまった場合のように、プロセスが、所望の動的メモリを割り当てることができないとき、プロセスは、変数MAX RETRY COUNTによって指定される再試行の最大回数を超えるまで、割当てを再試行する。注意すべき点であるが、再試行の規定の最大回数は０に設定することも可能である。MAX RETRY COUNTを超過すると、ステップ１０２５でchkpnt()（チェックポイント）が実行された後、ステップ１０３５でプロセスは終了する。既に指摘したように、プロセスが復旧されるとき、復旧サブルーチン１５８（図８Ａおよび図８Ｂ）が呼び出され、揮発性状態および持続性状態を最後のチェックポイント（換言すれば、終了の直前に実行されたチェックポイント）に復旧する。注意すべき点であるが、復旧サブルーチン１５８の実行時にプログラムカウンタの値が復旧されると、実行は、復旧サブルーチン１５８から揮発性状態チェックポイントサブルーチン１５４にジャンプする。復旧サブルーチン１５８は揮発性状態チェックポイントサブルーチン１５４へ、回復モードを示す正の返値とともに復帰する。このように、図１０の実施例では、正の返値によって、プログラム制御は、回復コードを実行する第１０４０行に進む。この例では、回復コードは、retry countを０にリセットして、所望の動的メモリの割当てを再試行することからなる。しかし、当業者には明らかなように、他の回復コードを実行することも可能である。注意すべき点であるが、リソース不足状態は過渡的である可能性があり、プロセスが環境の変化により復旧されるときには、同じプロセスが別の条件下で実行されて、リソース不足状態が迂回されることがある。しかし、リソース不足状態が持続性の場合、例えば、現在のマシンが単に、ユーザアプリケーションプロセスの要求を満たすには与えられたリソースでは十分ではない場合、途中終了を迂回するには、より大きい容量を有する別の処理ノードへのプロセスマイグレーションが必要なこともある。本発明の技術は、プロセスをあるワークステーション上で開始した後で、リソース不足状態に遭遇した後にのみ、より大きい容量の所望のリソースを有する別のマシンへプロセスを移動することが可能である。長い初期化の迂回多くのソフトウェアプログラムは、しばしば時間のかかる初期化ルーチンを含む。さらに、同じプログラムが相異なる入力データのセットに対して再実行される場合、各実行において、時間のかかる初期化ルーチンを繰り返す必要があることが多い。しかし、多くの場合、処理ルーチンの多くの実行が、同じ初期化された状態を、相異なる入力データで再使用することが可能である。この場合、初期化状態を保存し、対応するソフトウェアプログラムの将来の実行により異なる入力データのセットで使用するために復旧することにより、ソフトウェアプログラムの効率は大幅に改善される。本発明の特徴によれば、図１１に示すように、与えられたソフトウェアプログラムに関連する初期化状態をチェックポイント実行し、後で異なる入力データに対して実行するために復旧することができる。それぞれの異なる実行ごとに置換される入力ファイルはチェックポイントから除外して、新しい入力ファイルをそれぞれの新しい実行ごとに処理することが可能である。図１１に示すように、長い初期化を迂回する初期化迂回ルーチン１１００はステップ１１０５から開始される。まず、ステップ１１１０で、初期化迂回ルーチン１１００は、例えばコマンドライン、または、入力ファイル名のセットを含むデータファイルから、第１の入力パラメータのセットを読み出す。その後、ステップ１１１５で、与えられたユーザアプリケーションプロセスに適する初期化ルーチンが実行される。ステップ１１２０で、チェックポイントから除外すべきファイル、換言すれば、後のそれぞれの実行で置換すべきファイルが指定される。その後、ステップ１１３０で、揮発性状態と、前のステップで指定されなかった持続性状態の部分とがチェックポイント実行される。チェックポイント関数から制御が戻ると、ステップ１１３５で、チェックポイント関数からの返値が０より大きい（回復モードを示す）かどうかを判定するテストが実行される。ステップ１１３５で、返値が０より大きいと判定された場合、これは、初期化迂回ルーチン１１００の最初の実行であり、ステップ１１５０で、初期化状態と、第１の入力ファイルおよびパラメータのセットとに従って第１のデータのセットが処理される。ステップ１１６０で、さらに処理すべき入力ファイルおよびパラメータのセットがあるかどうかを判定するテストが実行される。ステップ１１６０で、さらに処理すべき入力ファイルおよびパラメータのセットがあると判定された場合、プログラム制御はステップ１１７０に進み、復旧サブルーチン１５８が正の返値で実行される。復旧サブルーチン１５８は、ステップ１１３０で設定されたチェックポイントにプロセス状態を復旧する。注意すべき点であるが、ステップ１１３０でチェックポイント実行されたオープンファイルテーブルは、第１の入力のセットに関連する各入力ファイルをリストしている。しかし、後続の実行では、オープンファイルテーブルにリストされた同じファイルディスクリプタのセットが、それぞれの実行に関連する入力ファイルに関連づけられる。こうして、既に指摘したように、復旧サブルーチン１５８は、ユーザがオープンファイルテーブルを変更しその変更を反映することを可能にする機構を有している。注意すべき点であるが、ステップ１１７０で、プロセス状態が最後のチェックポイントに復旧されると、プログラムカウンタも、そのチェックポイントに対応する値に復旧され、それにより、プログラム制御は、ステップ１１３０で実行されるチェックポイント関数にジャンプする。ステップ１１３０で、プログラム制御が、上記のように、正の返値でチェックポイントから復帰すると、ステップ１１３５で実行されるテストの結果、プログラム制御はステップ１１４０に進む。こうして、入力ファイル名のリストを含む次の入力パラメータのセットは、初期化ルーチンの再実行を必要とせずに、上記のようなステップ１１５０での実行のために、ステップ１１４０で読み出される。しかし、ステップ１１６０で、さらに処理すべき入力ファイルおよびパラメータのセットがないと判定されると、ステップ１１８０で、初期化迂回ルーチン１１００の実行は終了する。メモリ再設定時間が経つと、好ましくないメモリ状態が生じ、ソフトウェアプロセスの効率的実行を妨げるとともに、システム性能を徐々に劣化して、最終的にソフトウェア障害を引き起こすことがある。例えば、ソフトウェアプログラムは、多くの成功した市販品を含めて、ある実行パスに対して正しいメモリ解放を行わない場合に、メモリリークが起こることがある。割り当てられたメモリスペースが、メモリリークの結果、どのポインタからも参照されていないために、アクセスすることができなくなる。一般に、メモリリークは、割り当てられたメモリの第１ブロックを指すポインタが、第１ブロックを解放せずに、割当てメモリの第２ブロックを指すように再割当てされるときに起こる。メモリリークの結果、全体性能の累積的な劣化が生じ、理論的には、時間が経つと、プロセスはメモリを使い果たす。さらに、いくつかの市販のメモリマネージャによって提供されているメモリキャッシュおよび弱いメモリ再使用機構は、マシンが需要を満たす十分な物理的容量を有している場合でも、メモリ不足状態を生じることがある。例えば、ユーザアプリケーションプロセスが繰り返し小さいメモリブロック（例えば、３２バイト以下のブロック）を要求すると、メモリマネージャは、それらの小さいブロックを、解放後、別のリストで、あるいは、メモリキャッシュで、小さいメモリブロックに対する将来の予想される要求に対して管理する。こうして、これらの小さいブロックは、より大きいメモリ要求には利用できなくなる。小さいブロックに対する十分多くの要求があった場合、より大きいメモリ要求は、たとえ十分な物理的容量がある場合でも、拒否されることになる。弱いメモリ再使用機構とは、例えば３０メガバイトのメモリを有するマシンが、例えば１５メガバイトのメモリをまず割り当ててから解放するような場合に関するものである。その後、ユーザアプリケーションプロセスが１６メガバイトの割当てを要求すると、メモリ不足状態に遭遇する。その理由は、解放された１５メガバイトに１メガバイトを追加するのではなく、このメモリマネージャは解放された１５メガバイトを予約し、１６メガバイトを割り当てようとする。この場合、実際には十分な物理的容量があるのに、マシンのメモリ限界を超えるようにみえる。本発明の特徴によれば、図１２に示すメモリ再設定サブルーチン１２００は、プロセスのメモリを、揮発性状態の一部としての「クリーン」状態においてチェックポイント実行し、ソフトウェア障害を防ぐために、ときどきプロセスをそのクリーン状態にロールバックする。ステップ１２１０で、メモリ再設定サブルーチン１２００は、ループインデックスｉを０にセットする。その後、ステップ１２１５で、適当な初期化ルーチンを実行する。注意すべき点であるが、初期化された状態は、チェックポイント実行される揮発性状態の一部である。ステップ１２２０で、すべてのユーザファイルをチェックポイントから除外するように指定する。こうして、チェックポイントが設定され、後で復旧されるときに、クリーンなメモリ状態のみが復旧されることになる。さらに、すべての持続性状態、換言すれば、すべての入力ファイルをチェックポイントから除外することによって、ユーザファイルの現在の内容が復旧後に維持される。ステップ１２３０で、揮発性状態チェックポイントサブルーチン１５４（図６）を実行することによって、揮発性状態がチェックポイント実行される。その後、ステップ１２４０で、初期化状態およびループインデックスｉの現在の値に基づいて、所望の処理タスクが実行される。ステップ１２４５で、前のステップで実行された処理タスクの結果が、周知のようにして、出力バッファに書き込まれる。出力バッファの内容は、バッファがフルになるまで、あるいは、flushシステムコールが実行されるまでは、ディスクのような目的とする宛先に送られない。ステップ１２５０で、さらに処理すべきループインデックスｉの値があるかどうかを判定するテストが実行される。ステップ１２５０で、さらに処理すべきループインデックスｉの値があると判定された場合、ステップ１２５５で、ループインデックスがインクリメントされる。その後、ステップ１２７０で、ループインデックスｉの現在の値が、指定された再設定周期の倍数であるかどうかを判定するテストが実行される。換言すれば、１５回の実行ごとにクリーンなメモリ状態を復旧すべきである場合、ループインデックスの現在の値が１５の倍数であるかどうかを判定するテストが実行される。ステップ１２７０で、ループインデックスｉの現在の値が、指定された再設定周期の倍数でないと判定された場合、プログラム制御はステップ１２４０に戻り、上記のようにして処理を継続する。しかし、ステップ１２７０で、ループインデックスｉの現在の値が、指定された再設定周期の倍数であると判定された場合、ステップ１２７５で、出力バッファがフラッシュされた後、メモリはクリーン状態に復旧される。その後、ステップ１２８０で、返値をループインデックスｉの現在の値に等しくして、復旧サブルーチン１５８を実行することによって、揮発性状態にロールバックする。チェックポイントはユーザファイルを含まないため、クリーンなメモリ状態のみが復旧される。既に指摘したように、復旧サブルーチン１５８は、ステップ１２３０で、チェックポイント関数から返値とともに復帰する。そこで、この返値（ループインデックスに等しい）を保持することによって、ユーザアプリケーションプロセスの正しい進行が保証される。復旧サブルーチン１５８がチェックポイント関数から復帰すると、プログラム制御はステップ１２４０に進み、上記の通り継続する。ステップ１２５０で、さらに処理すべきループインデックスｉの値がないと判定された場合、プログラム制御はステップ１２９０に進み、メモリ再設定サブルーチン１２００の実行は終了する。理解されるように、ここで説明した実施例およびその変形例は本発明の単なる例示であり、当業者であれば、本発明の技術的範囲を離れることなく、さまざまな変形例を実施することが可能である。DETAILED DESCRIPTION OF THE INVENTION Checkpoint and recovery system for persistent stateTechnical field to which the invention belongs The present invention provides a system for executing and restoring a process state to a checkpoint. Process status, especially including delayed checkpoints of persistent process state System for suspending and restoring the state.Conventional technology Increasingly, users of software applications find that software is Less likely to cause a hardware failure (fault), or at least for failure It requires resistance. For example, users of a telecommunications switching system Requires that the stem be continuously available. In addition, the communication For financial transactions, such as cash machines, or other important data, Customers also demand the highest data integrity. Thus, it can cause consequences for user application processes Various software inspection devices to detect many programming errors Tooling tools have been developed. For example, Pure from Sunnyvale, California, USA Software, Inc., and is described in U.S. Pat. No. 5,193,180. Purify^TMSoftware inspection tools can detect memory access errors and We provide a system to detect moly leaks. Purify^TMThe system is Monitor the allocation and initialization status of each byte. Further notes Purify for each software instruction that accesses the^TMSystem runs test The program has not written to unallocated memory, and Guarantee that no data is read from the unallocated or unallocated memory. Purify^TMSoftware inspection and debugging tools like the system Many programming that can lead to failure in the application process It provides a valid basis for detecting errors, but it does not No matter how many checks, verifications or checks are performed during And removes them for complete reliability in user application programs I can't give it. Therefore, residual failure due to untested boundary conditions, not predicted Exceptions and unexpected execution environments bypass inspection and bagging processes It has been observed that these can surface when triggered during program execution. Can cause the application process to crash or hang. Service interruption. Therefore, if the user application minimizes the amount of lost information and It would be desirable to provide a mechanism that can recover from the failure. Therefore, the hardware Software and software failures to minimize the amount of lost information. Several checkpointing and recovery methods have been proposed for . Checkpoint execution and rollback recovery Generally, R.A. Koo and S. Toueg, ″ Checkpointing and Rollback-Recovery for Distributed Systems ", IEEE Trans. Software Eng., Vol. SE-13, No. 1, pp. 2 3-31 (January 1987). In general, checkpoints and recovery The old technology saves the state of the process periodically during normal execution and then after a failure , Restore the saved state. In this way, the amount of work lost is To the progress made by the user application since the checkpoint Is done. Note that the state of the process can be volatile or persistent. Is included. Volatile states contain process information that would normally be lost in the event of a fault Is included. The persistent state contains the current execution of the user application process. All relevant user files are included. Persistent states are generally impaired Is not lost, but to maintain data integrity, the same port as the recovered volatile state is used. Int need to restore the sustained state. Existing checkpoint execution and recovery techniques rely on volatile state checkpoints. However, these methods do not checkpoint persistent status. I haven't dealt with int execution enough. According to one approach, all In the persistent state, in other words, all user files, each checkpoint in the volatile state A checkpoint is performed at the point. Clearly, the overhead associated with this method Can be very large for most applications. Existing Unix^TMCheck Another method, such as a checkpoint library, is to checkpoint volatile states. File of the active or open user file when Checkpoint only the scripter. However, this method does not The user file is created or activated after the If you do, you will run into integrity problems. The reason is that the process is the last checkpoint Is restored, a new one is created since the last checkpoint or Changes to the activated file are not undone. this Such inconsistencies often result in corrupt files that are not detected obtain. Such checkpointing and recovery techniques are useful in many applications. Works well in an environment, but has some limitations. These limitations are overcome This will increase the integrity and transparency of the checkpoint execution system, It also expands its usefulness to other applications that were previously unthinkable. Especially, Most traditional checkpointing and recovery techniques rely on disaster recovery. Do not take advantage of the benefits of checkpointing and recovery other than that. As is clear from the above explanation, the whole persistent state, or its necessary parts, Checkpoint execution and enable each checkpoint to be included in Recovery techniques are needed. In addition, checking for persistent states until an inconsistency occurs Technology for delayed checkpoint execution and recovery that delays It is important. In addition, save as a starting point for performing new tasks. Selected part of the persistent state so that the intermediate state can be used Checkpoints can be excluded from a given checkpoint Execution and recovery systems are needed. In addition, protected state recovery Before restoring the current process, ensure that the previous values are retained after the checkpoint is restored. Checkpoints that can protect selected parts of the access state and A recovery system is needed.Summary of the Invention In general, according to one aspect of the invention, a checkpoint and recovery system is provided. The system saves the process state during normal execution and then, for example, recovers after a failure. The user application process to restore the saved state during And implement checkpoint and recovery techniques. According to a feature of the invention, Checkpoint and recovery systems are designed for both volatile and persistent states. Perform a checkpoint. In one embodiment, the persistent state checkpoint Line is inconsistent between checkpointed volatile state and user file Delay check to delay taking a persistent state checkpoint until Consists of the lockpoint method. According to another aspect of the invention, a checkpoint and recovery system is provided. More specifically, the user or user application process It is possible to specify that the selected part should be excluded from the checkpoint it can. In this way, the desired intermediate state is checkpointed and a new It can be used as a starting point for performing processing tasks. For example, you The application process requires a long initialization process and then If you are processing some input using a synchronized state, check the input file. Checkpoints can be excluded from the it can. After that, the checkpoint executed initialization state is restored, and new entry Processing tasks can be performed for each set of input files. Thus, Yu The user application process can transform the desired or predictable state into a future Input can be processed. In another embodiment, the checkpoints and Recovery system recovers the entire persistence state, in other words, all user files , Used to exclude parts of the process state that are checkpointed It is possible. According to another aspect of the invention, a user executing on a computer system. Checkpointing and restoring the application process is realized You. In this way, the user application process is responsible for the volatile state and user And a persistent state consisting of user files. The method of the present invention Is Performing a checkpoint of the volatile state at the checkpoint location; Checkpoint that will monitor the persistence state and change the persistence state A monitor step for detecting file operations after the position; If the monitoring step detects that a change in the persistence state is to be performed, Checkpoint at least the part of the sexual state that will be changed Steps and Checkpointing can be performed by restoring the process state to the checkpoint position. Reverting changes to the persistence state since the Resume execution of the user application process from the checkpoint position It consists of steps. According to yet another aspect of the present invention, a user application process A method of restoring the associated initialized state is realized. In this way, the user An application process has a process state and at least two sets of inputs Perform processing tasks based on the initialization state for the file. The method of the present invention , (A) A process for initializing a user application process to form an initialized state Tep, (B) Specify the input file to be excluded from the process state checkpoint Steps (C) Checkpointing a part of the process state that is not excluded Steps and (D) processing tasks based on the initialization state and the current set of input files Steps to perform; (E) Put the user application process in a state where the checkpoint has been executed A recovery step to recover and generate a predefined return value indicating the recovery mode; , (F) If the recovery step returns a predefined return value, a new input Obtaining a set of files and replacing the excluded input files; (G) Repeat steps d to f for each set of input files to be processed. Consists of Tep. A more complete understanding of the present invention may be had from the more features and advantages of the present invention. And with reference to the detailed description and drawings.BRIEF DESCRIPTION OF THE FIGURES FIG. 1 is a schematic diagram showing a checkpoint execution and recovery system according to the present invention. It is a block diagram. FIG. 2 is an execution graph of the user application process, in which the volatile check is performed. Process migration to a new machine Show FIG. 3 shows the relationship between the user application process and the operating system. Monitor file system calls for inconsistencies between persistent and volatile states FIG. 4 illustrates an interrupt routine that detects a change to a persistent state that will occur. Figure 4 shows the persistence for each file that has changed since the last volatile checkpoint. Indicates the persistence checkpoint table that stores the checkpoint information You. FIG. 5 illustrates an exemplary implementation that is called before the execution of the user application process. 9 is a flowchart describing a before-line checkpoint subroutine. FIG. 6 illustrates an example called to checkpoint a volatile state. 5 is a flowchart describing a volatile state checkpoint subroutine. FIG. 7 illustrates an exemplary implementation of the file system call interrupt subroutine of FIG. It is a flowchart which describes. This means that changes can cause inconsistencies between volatile and persistent states. Called to checkpoint the user file before it occurs. FIG. 8A and FIG. 8B collectively show return values capable of controlling processing after restoration. Together with the specified checkpoint to restore the process state. 4 is a flowchart describing an exemplary recovery subroutine. FIG. 9 can be called after execution of a user application process 5 is a flow diagram describing an exemplary cleanup subroutine. Figure 10 shows software termination caused by resource shortage Here is a sample source code that incorporates the features of the present invention to bypass. FIG. 11 checks the initialization state of a set of additional input files and parameters. Of the present invention to execute the lockpoint and restore the process state to its initialized state. In a flowchart describing an exemplary routine that bypasses long initialization, incorporating features is there. FIG. 12 shows a checkpoint of a clean memory state and its clean state. An example incorporating the features of the present invention to restore the process state to the memory state Is a flowchart describing a typical memory reset subroutine.Detailed description FIG. 1 shows a checkpoint restoration system 10 according to the present invention. Further below As described, according to the checkpoint recovery system 10, during normal execution, Process state, and then save the saved state, for example, during recovery mode after a failure. Checkpoint in the user application process to recover And recovery technology can be implemented. In this way, the application Work lost by the process is generated since the last checkpoint It is limited to what was done. System architecture As shown in FIG. 1, the checkpoint restoration system 10 disclosed here Computer, workstation or other general purpose computer device It can be implemented on such a processing node 20. Processing nodes 20 Both have one processing unit 25 and memory storage device 30. No processing The processing unit 25 and the memory storage device 30 of the Or on the local processing node 20 for intra-node communication. It can be interconnected by an inter-process communication (IPC) facility. Further In a known manner, each node 20 performs serial or parallel inter-node communication. Network interface 70 to a communication link 75 for other nodes. Interconnected with a remote or remote centralized recovery coordinator (not shown) Is also possible. The network interface 70 is, for example, ATM host adapter available from Fore Systems, Inc. of Pittsburgh, N.A. Puttacard. In this way, the user application process Permanent or long term hardware failure may cause If it cannot recover, the user application process It can be exported to a processing node. This technology is often It is called smigration. Processing unit 25 may operate as a single processor or in parallel. It can be implemented as several processors. Memory storage device 30 Is an area of volatile memory which is generally unstable. Instructions that can be interpreted and executed can be stored. In one embodiment, The regenerative memory storage device 30 is a process executed by the processing unit 25. Software code associated with each user application process, such as 40 Together with the checkpoint library called by the user process 40 The re-function 50 is stored. Further, the volatile memory storage device 30 may be User application process 40 and checkpoint recovery license Data segment section storing data associated with each of the library functions 50 Option 55 is included. Checkpoint called by user application process 40 Library function 50 is selected from checkpoint recovery library 150 . Checkpoint recovery library 150 can also be stored locally. Yes, or stored on a centralized file system such as file system 120 It is also possible to pay. File systems such as file system 120 Provide a centralized warehouse for storing user accessible files. General In addition, the centralized file system 120 is a non-volatile or persistent memory area. Thus, information can be held without a power supply. Included in checkpoint recovery library 150, as described further below Functions are written in a high-level programming language such as the C programming language. User-level library functions. Checkpoint recovery library 15 The function in 0 can be used to save process state during normal execution, or During the recovery mode after a failure, the user application is required to restore the saved state. Can be read by the application process. In one embodiment, checkpoint recovery The user process 40 that calls a function from the library 150 Or the function link called by the dynamic linking process. Bound with the code. As shown in FIG. 1, the checkpoint recovery library 150 It has a point subroutine 152. Checkpoint subroutine before execution 152 is called before the execution of the user application process. Check before execution The lockpoint subroutine 152 is described in more detail below with respect to FIG. . In addition, the checkpoint recovery library 150 A subroutine 154 is provided. Volatile state checkpoint subroutine 1 54 is volatile when called by the user application process 40. From the memory 30 to a non-volatile memory area such as the disk 100, the volatile state Store a copy of. Checkpoint disk 100 is located on processing node 20 It can be local or remote to the communication network. It can also be on a node. Volatile state checkpoint subroutine The details of the button 154 will be described later with reference to FIG. In addition, checkpoi Component recovery library 150 is a file system call interrupt subroutine 15 6. File system call interrupt subroutine 156 has a persistent state Provides a delay technique for performing a checkpoint on a desired portion of the File The system call interrupt subroutine 156 is further described in FIGS. And will be described later. The library 150 has a restoration subroutine 158. Recovery sub blue The routine 158 returns the user application process to the desired checkpoint. Called to obsolete. 8A and FIG. 8B will be described later. As already pointed out, the recovery subroutine 158 User specifies user files to be excluded from the persistence state checkpoint Provides a mechanism that allows the user application process to Ah Or it allows to process future inputs from a predictable state. Finally, The checkpoint recovery library 150 executes a cleanup subroutine 160. Have. The cleanup subroutine 160, if necessary, Run the user application process to remove the Called after a line. In various implementations, the recovery subroutine 158 will be apparent to one of ordinary skill in the art. It can also be started automatically in response to a detected fault, or Manually initiated by the user, for example, by command line input. Both are possible. In the automatic mounting, as shown in FIG. Can have a watchdog 80. Watchdog 80 Error detection monitor 85 that monitors the processes running on each node including. The error detection monitor 85 indicates that the process is hung or Execution on node 20, such as process 40, to determine if Continuously monitor running application processes. The monitoring performed by the error detection monitor 85 must be active Can also be passive. In an active monitoring configuration, the watch The process 80 uses the inter-process communication (IPC) facility on the local node 20 Monitor by periodically sending messages to the Poll each application process to determine the status of that process. , To determine if the process is still active. In the passive monitoring configuration, each application process is 0, which is used by a user application such as process 40. When called by the watch process, the watchdog 80 , A heartbeat message indicating that process 40 is still active Send a page. Before the end of the specified interval, the watchdog 80 If no signal is received from the process 40, the watchdog 80 Presumed that the solution process was hung or crashed. As will be further described later, the error detection monitor 85 controls the user application. When a failure in the restart process 40 is detected, the restart subsystem 90 From the last checkpoint, the failed application process Attempt to recover a failed application process by performing a restart . The restart subsystem 90 performs a recovery subroutine 158 when a failure is detected. To restart the failed user application process. Checkpoint and recovery concepts and definitions For a general explanation of checkpoint and recovery concepts and definitions, see For example, Yi-Min Wang et al., “Progressive Retry Technique for Software Error Recovery in Distributed Systems ″, Proc. Of 23rd IEEE Conf. On Fault-To lerant Computing Systems (FTCS), pp. 138-144 (June 1993), or R. Koo and S. Toueg, ″ Checkpointing and Rollback-Recovery for Distribut ed Systems ", IEEE Trans. Software Eng., Vol. SE-13, No. 1, pp. 23-31 (19 Jan. 1987). In general, checkpoint and recovery techniques are To minimize the amount of work lost, sometimes during normal program execution. Process state, and then restore the saved state, for example, after a failure . FIG. 2 illustrates the execution of a user application process, such as process 40. . While the user application process 40 continues to execute, the volatile checkpoint Int VC₁, VC_TwoAnd VC_ThreeCheckpoint for volatile state Be thrown out. Here, the term volatile state includes the program stack, open File descriptors, static and dynamic Information that would normally be lost in the event of a failure, such as data segments, and the operating Such as operating system registers, program counters and stack pointers Related to the operating system kernel essential to the current program execution Data structures. Further, in accordance with a feature of the present invention, user application process 40 is Perform file operations that change the persistence state, such as user file attributes In this case, the affected files are Before being executed, a persistent checkpoint PC_{3 '}And PC_Three _″Indicated by A checkpoint is performed so that Here, the term persistent state , Yu User files associated with the current execution of the user application process Is included. The persistence state is generally not lost in the event of a failure, but the persistence checkpoint The process is triggered by the last volatile checkpoint, for example, when a fault is detected. Ensure that the persistent state is consistent with the volatile state when rolling back to Testify. Note that the persistence state indicates that updates to a given file Recorded until inconsistent with the volatile state associated with the last checkpoint. Not. As described below, the persistent checkpoint PC_{3 '}And PC_Three _″By Undo all changes to the persistent state since the last volatile checkpoint Is done. Thus, "F₁If a failure is detected at the point indicated by The emitting state is the last volatile checkpoint VC_ThreeCheckpoints related to Checkpoint VC by restoring data_ThreeRoll back to be able to. In addition, a persistent checkpoint PC_{3 '}And PC_Three _″By , Last volatile checkpoint VC_ThreeSubsequent changes to the persistence state And returned to. Thus, after a rollback, the entire persistent state is the last volatile chip Check Point VC_ThreeConsistent with the volatile state as it existed at the time. Note The point is, if the process cannot be restarted on machine A, As shown, the process migration causes the process to look like machine B. It is possible to restart on an alternative machine. Monitoring persistence status by interrupting file system calls As noted earlier, the persistent state includes the current state of the user application process. Contains all user files related to the current run. Generally, user apps Application process can access and modify user files The only way to do this is to send the file system to the operating system kernel. It is due to Mucor. Therefore, depending on the user application process Checkpoint recovery system interrupts each file system call generated. Identify all possible changes to the persistent state, as assessed by system 10 Is possible. Thus, as shown conceptually in FIG. All file systems created by the user application process The call is made when the desired file operation is actually performed by the operating system 300. Before being executed, it is interrupted and monitored by the interrupt routine 156. This This will be described later with reference to FIG. In this way, file operations are persistent If you are trying to change a file that is related to the status, the status of the affected file Can be recorded to ensure consistency. In one embodiment, the persistent state checkpoint is the persistent checkpoint illustrated in FIG. Recorded in the int table 400. The persistence checkpoint table 400 is , Stored in persistent memory, such as a disk, every time the table 400 is changed. Stored on the disk. Each persistence checkpoint table 400 contains a specific Checkpoint related to the user application process by id Associated with the particular volatile checkpoint identified, lines 405 and 410 Have multiple rows. Each row has something after the associated volatile checkpoint Corresponding to the changed user file. Each indicated by "file name" Per file, the persistence checkpoint table 400 may change There is an entry for each file attribute with. For example, a persistent checkpoint The table 400 includes a column 435 for recording the “change time” of each file, A column 440 for recording the “access mode” of each file, and the current Includes a column 445 for recording the current "size". In one embodiment, each entry in table 400 contains, for a given file, When a row is created, it is initialized with a default value such as "-1". afterwards When a file attribute is changed, the current attribute value can be recorded before the change. Wear. In this way, the given attribute of the file to be recovered is "-1". If so, the attribute has not changed and does not need to be restored. Regarding FIG. As described later, the entry is stored in the file system call interrupt subroutine 15. 6 is created in the persistence checkpoint table 400. further, As described below with respect to FIGS. 8A and 8B, checkpoint Identified by id value During the recovery of a particular checkpoint to be performed, the recovery subroutine Access the checkpoint table 400 and use the information contained in Continued Restore sexual condition. Checkpoint recovery library function Checkpoint subroutine before execution As already pointed out, the checkpoint recovery library 150 And a checkpoint subroutine 152. Checkpoint subroutine before execution Step 152 is executed before the user application process 40 is executed. For example , Programs written in the C programming language usually have a "main" routine. Start execution from the first line Therefore, the pre-execution checkpoint subroutine The execution of the routine 152 should be called before the execution of the "main" routine. The checkpoint restoration system 10 has two modes, the insert mode and the transparent mode. Provides two modes of operation for executing the checkpoint. Insert mode is By inserting a checkpoint function at the desired location in the source code, The application process to implement a checkpoint mechanism. You. Transparent mode automatically performs checkpoints at specified time intervals Provide a mechanism. According to the transparent mode, the user application process Without the need to change or recompile the user application process A checkpoint mechanism can be incorporated. As described later, in transparent mode, checkpoints are performed at predefined intervals. To start a close, the pre-execution checkpoint subroutine 152 A lock daemon process is created. Each specified interval, as described below Spawned clock daemon to initiate a checkpoint at the end of A process interrupt call is issued by the operating system at the direction of the process. To the associated user application process. As shown in FIG. 5, the pre-execution checkpoint subroutine 152 Starting at 500, then at step 505, checkpoint recovery system Open File Table and Persistence Checkpoint Required by 10 Initialize a data structure such as the client table 400. Then, in step 520, for example, from the user's designation on the command line , Alternatively, the user application process is set to insert mode A test to determine if it is running in transparent mode or Execute. At step 520, the user application process is in transparent mode If it is determined that execution has been performed, in step 525, for example, the fork system code Creates a clock daemon process. As already pointed out, The lock daemon process is executed by the user application process at specified intervals. Acts as a checkpoint timer that starts the checkpoint of One practice In the example, the checkpoint is every 30 minutes unless a valley interval is specified. Started at a default interval such as On the other hand, at step 520, the user application process runs in insert mode. If it is determined that the process has been executed, the Checkpoints are only initiated when called. In step 540, a correct check for the user application process A test is performed to determine if the point file already exists. Paraphrase If this is the case, the test is running in normal or recovery mode. Is determined. Note that the user application process Upon successful completion of the process, unless otherwise specified, the clear is performed as described below with respect to FIG. Startup subroutine 160 is associated with the user application process. Delete the checkpoint file to be executed. Thus, the user application If a checkpoint file exists at the start of the process, e.g. The previous execution did not end normally, or the user application process Requested that the checkpoint file be stored for later recovery. Either. At step 540, the user application process If it is determined that the correct checkpoint file exists, check before execution The point subroutine 152 returns and will be described later with respect to FIGS. 8A and 8B. The data related to the existing checkpoint file was recovered and recovered Start the execution of the user application process from the time of the checkpoint Therefore, in step 550, execution of the recovery subroutine 158 is started. On the other hand, in step 540, the correct check for the user application process is performed. If it is determined that the checkpoint file does not exist, The subroutine 152 returns and at step 560, the user application program The execution of the process starts. Volatile state checkpoint subroutine As already pointed out, the checkpoint recovery library 150 has a volatile state. It has a checkpoint subroutine 154. Volatile state checkpointer The routine 154 states that in transparent mode, a checkpoint should be initiated. By an interrupt signal from the clock daemon or in insert mode Is a checkpoint inserted in the source code of the user application process. Called when an event function call is executed. In addition, as described below, The spontaneous state checkpoint subroutine 154 returns the program counter value to It is called indirectly from the recovery subroutine 158 after being aged. The volatile state checkpoint subroutine 154 is a user application Stores all information needed to recover the process, which is lost in case of failure I do. In one embodiment, the volatile state checkpoint subroutine 154 includes Checkpoint available to identify checkpoint intervals passed the id argument . The volatile state checkpoint subroutine 154 checkspoint passed the id argument If not, the previous checkpoint data is overwritten. checkpoint id discount Numbers can be global variables to later checkpoint the persistence state. The file system call interrupt subroutine 156 to be implemented has an appropriate (current ) To associate a persistent state checkpoint with a volatile checkpoint, Can be accessed. As noted above, hardware for temporary storage of values in the central processing unit User registers, such as hardware registers, stack pointers, and program counters. Some volatile information related to the current execution of the application process is Managed by the rating system kernel. These memory elements are usually Is not accessible by the user application process, but Operating systems are typically required by specific user application processes. Checkpoints required operating system information To provide a routine. Operating system to perform this task The routine provided by the system, at step 610, registers, This is executed to save the contents of the pointer and the program counter. example For example, the Unix operating system Access data structures and save them in the declared global data structure Offers tjmp calls. Those global data structures are then A checkpoint can be performed as part of the sexual state. setjmp system co For details of the operation of the rule, see, for example, W.W. R. Stevens, "Advanced Programmin g in the Unix Environment ", pp.174-180 (Addison Wesley, 1992) ing. Thereafter, program control proceeds to step 620. It is important to note that During execution of old subroutine 158 (FIGS. 8A and 8B), After recovery of the program, the value of the program counter corresponds to the restored checkpoint. It is restored to the value. Therefore, when the value of the program counter is changed, The old subroutine 158 jumps to the position immediately after the execution of step 610. And It should be further noted that the recovery subroutine 158 must be greater than zero. Returns the return value. This can be used to control the flow of execution after recovery. You. For example, for a predefined return value, a code is executed, Another code sequence is executed in case of another predefined return value . Thus, in step 620, an operation such as the setjmp system call Test to determine whether the return value from the Be executed. As noted above, the restore subroutine 158 causes The return value can be used in recovery mode. In step 620, the return value is If it is determined that it is not 0, the volatile state checkpoint subroutine 154 The current execution is called from the recovery subroutine 158 in recovery mode and Program control proceeds directly to step 670 without performing a checkpoint. No. On the other hand, if it is determined in step 620 that the return value is equal to 0, the volatile state check is performed. The current execution of the checkpoint subroutine 154 Instead of being called, the volatile state checkpoint subroutine 154 Continue volatile checkpoint. That is, in step 630, the volatile check is performed. File descriptors of all open files at the time of the File, along with the file name and current location of the file Stored in a table. The open file table contains a file for each open file. Includes file descriptor, file name and location. Then, step 640 The data segment associated with the user application process All dynamically and statically allocated such as file variables and static variables Including the memory and the open file table. Finally, step At step 650, the current contents of the stack are saved. Execution of the volatile state checkpoint subroutine 154 ends at step 670. And return with the indicated return value. Volatile state checkpoint If subroutine 154 returns a value of 0, this is a checkpoint Indicates success. Further, the volatile state checkpoint subroutine 15 If 4 returns a value greater than 0, this can be used to control the flow of execution Execution has returned indirectly from the recovery subroutine 158 with a valid return value. Is shown. File system call interrupt subroutine As already pointed out, the checkpoint recovery library 150 has a persistent state File system call interrupt subroutine 156 implementing checkpoint including. File system call interrupt subroutine 156 To file system calls that may change the attributes of the file, if necessary Performs a delayed checkpoint of the changed portion of the persistent state. The file system call interrupt subroutine 156 performs the required file operations. Perform a persistent state checkpoint before actually executing In addition, The file system interrupt subroutine 156 can be held only as necessary. Perform a checkpoint of the persistent state. The file system call interrupt subroutine 156 has The process starts at step 700 when a file system call is received. Steps At 710, the interrupted file operation should begin setting checkpoints A test is performed to determine whether to change file attributes. Step 71 0 indicates that the interrupted file operation should start setting checkpoints. If it is determined not to change the file attribute, the program control proceeds to step 750. The desired file operation is executed as described later. On the other hand, at step 710, the interrupted file operation sets a checkpoint. If it is determined that the file attribute for which the setting should be started is changed, in step 720, The user performs, for example, a function call or enters command line arguments , Or by setting an environment variable, the current file is checked A test is performed to determine if it has been specified to be excluded from the list. This The user or user application process is given a Determines whether a file should be included in the persistent state checkpoint And can be specified selectively. At step 720, the current file should be excluded from the checkpoint Is determined, the program control proceeds to step 750, where Perform the desired file operation. On the other hand, in step 720, the current file is If it is determined that it should not be excluded from the check point, Global variable checkpoint The last volatile check identified by the current value of id This file determines whether a checkpoint has already been performed since the The specified test is performed. In step 730, the last volatile checkpoint If this file is subsequently determined to have been checkpointed, The program control proceeds to step 750, where a desired file operation is performed as described later. Run. On the other hand, in step 730, this file If it is determined that the checkpoint has not been executed, step 740 Creates a shadow copy of this file, and gives the file name and attribute The previous value to the checkpoint Persistence checkpoint table corresponding to the current value of id This file is checkpointed by appending to You. In an alternative embodiment, the persistence state checkpoints each file by attribute. Perform a checkpoint on the attributes affected by the current file system call. Checkpointing only genders can further optimize It is. In other words, file operations affect only a subset of all attributes, A subset of the affected attributes before the file operation is performed in step 750 Only the checkpoint needs to be executed. For example, a write system call already exists If you only add data to the end of the file, the volatile The file contents that existed at the checkpoint are not changed, so the file Checkpoint the file size without checking the contents. Is enough. After recovery, this file can be truncated to an appropriate size. is there. After performing a checkpoint on the file in step 740, At step 750, the desired file operation can be performed. Persistent state Checkpoints are recorded before file operations are performed, so they are not persistent. The information stored in the checkpoint table 400 is the last volatile checkpoint. Can be used to undo changes made to each user file since It is possible. At step 750, after the desired file operation has been performed, the file Execution of the system call interrupt subroutine 156 ends at step 760, and Return to execution of user application process. Recovery subroutine As already pointed out, the checkpoint recovery library 150 is not And a recovery subroutine 158 shown in FIG. 8B. The recovery subroutine 158 is an example For example, after a failure is detected, the watchdog 80 When the application restarts from the correct checkpoint, or A rollback function call is inserted in the source code corresponding to the application process. Called when it is running. Here, the term rollback is used Or indicates a recovery initiated by the user application process, The term is used to indicate recovery after a failure with the correct checkpoint file. Used. In one embodiment, the following arguments are passed to the recovery subroutine 158: . • The value of mode indicates whether the current run is in recovery mode or rollback. Indicates whether the mode is the lock mode. ・ Checkpoint id (checkpoint ID) value and return value (return value) Is returned after the execution of the restoration subroutine 158. ・ Protected list of variables (protected variables) Even after being restored to the default, the value before restoration is maintained. Note that checkpoint If no id value is specified, the process will It is restored to a later checkpoint. Furthermore, return If value is not specified , A positive return value (for example, 1) is used. The recovery subroutine 158 is instructed Acts to restore the volatile and persistent state corresponding to the checkpoint. You. As described below, the restore subroutine 158 restores a volatile checkpoint. Based on changes made to persistent state since the restored volatile checkpoint. Reverting guarantees consistency between volatile and persistent states. According to a feature of the invention, the recovery subroutine 158 is Return when called by the process value and protected variables An array is specified. In one embodiment, the recovery subroutine 158 is Protected when rolling back to finger by variables array The current value of the indicated variable is return protected with the current value of the value variable . Thus, after a recovery to a particular checkpoint, the return specified before the recovery value is maintained and can be used to control the flow of execution after recovery It is. In addition, if the user or user application process If you do not want to roll the number back to a particular checkpoint, d Using the variables mechanism, specify the variables that should keep their current values after recovery Can be return If value is not specified, 1 is used as default value Can be. As shown in FIG. 8A, when called, the recovery subroutine 158 proceeds to step 8 It starts from 00. Then, at step 810, checkpoint indicated by the id argument The persistence checkpoint table 400 (FIG. 4) corresponding to the value to be read is read. You. At step 815, the user can, for example, by command line input or Depending on the setting of the environment variable, it is listed in the persistence checkpoint table 400. To indicate that the shadow file must not be recovered. Test to determine whether the int table 400 has been indicated to be changed Is executed. In step 815, the user sets the persistence checkpoint table 4 If it is determined that the user has instructed that 00 should be changed, then in step 820, The table 400 is changed according to the specified change. After the persistence checkpoint table 400 is changed, if necessary, At step 825, the shadow files corresponding to each file listed in the table 400 are displayed. The file is searched from the appropriate checkpoint data and its shadow file is By copying over the existing file, the persistence checkpoint table 4 00, the persistent state is restored. In addition, a persistent checkpoint table The attributes of each file listed in the file 400 are It is changed according to the value recorded in the entry. Then, in step 830, the current execution mode of the recovery subroutine 158 is Recovery mode after failure or rollback mode initiated by user Is and protected Determine if values in variables array are correct The test runs. At step 830, the current execution of the recovery subroutine 158 Mode is rollback mode, protected if the values in the variables array are correct If determined, in step 835, the data segment Protected while the event is restored protect variables specified by variables array Variables are copied from the data segment to a temporary file to . Then, at step 840, checkpoint the volatile key identified by the id argument The checkpoint file is read. In step 845, the Using the obtained volatile checkpoint file, open file table The containing data segment is restored. Then, at step 850, the current execution mode of the recovery subroutine 158 is Whether the device is in the callback mode and protected variables array value is positive The test to determine if it is acceptable is performed again. In step 850, the recovery sub The current execution mode of the routine 158 is the rollback mode, va If the value of the riables array is determined to be correct, at step 855, protected The variables specified by the variables array are protected in the temporary file. From the specified location to the data segment and returned. In this way, prot expected Each variable specified in the variables array keeps its value before restoration. At step 865, the user may enter a command line Indicates that the open file table should be changed by setting environment variables. A test is performed to determine if At step 865, the user If it is determined that the command indicates that the open file should be changed, the specified change Is executed in step 870. For example, a section later entitled "Bypassing Long Initialization" In one application, including the features of the present invention, described in The punfile table lists the first set of previously processed input files. To For each subsequent set of inputs to be processed, a first set of input files To replace the file with a set of input files suitable for the current run. Change the file table. After the open file table is changed, if necessary, at step 875 , The file descriptor indicated in the open file table is restored . In other words, for each entry in the open file table, the file is Opened, the file name is associated with the indicated file descriptor, The current position of the file is adjusted to the position recorded in the open file table entry. Is adjusted. Thereafter, at step 880, stack space is allocated and At step 885, the stack reads the volatile checkpoint read at step 840. Is restored according to the information in the event file. As noted above, hardware for temporary storage of values in the central processing unit User registers, such as hardware registers, stack pointers, and program counters. Some volatile information related to the execution of the application process Managed by the operating system kernel. These memory elements are usually Not accessible by the application process but operating System is generally required by a particular user application process. Provides routines that allow you to recover operating system information ing. Provided by the operating system to perform this task. The routine that is executed determines in step 890 the registers, stack pointer and program This is executed to restore the contents of the ram counter. For example, Unix operating System recovers these operating system data structures long Offers jmp call. See the example for details on the behavior of the longjmp system call. For example, W. R. It is mentioned in Stevens, op. As pointed out above, the value of the program counter indicates that the checkpoint has been restored. When the value recorded at the time of recovery is restored, the execution of the recovery subroutine Jump to step 620 of state checkpoint subroutine 154 (FIG. 6). You. Thus, the recovery subroutine 158 is a volatile state checkpoint subroutine. Return from the routine 154 effectively. Further, a restoration subroutine 15 8 is the specified return value and protected Variables specified in the variables array Returns with the number kept at the value before restoration. Cleanup subroutine As already pointed out, the checkpoint recovery library 150 Cleanup subroutine 160 executed after the execution of the application process including. As shown in FIG. 9, the cleanup subroutine 160 The process starts at step 900 when the application process ends. Step In step 910, the current execution mode of the user application process is set to the transparent mode. A test is performed to determine if In step 910, the current execution If the mode is determined to be the transparent mode, in step 930, the pre-execution check is performed. The clock daemon process created by the It is deleted (killed). Thereafter, at step 950, a check associated with the user application process is performed. A test is performed to determine whether the lockpoint file should be maintained. S If it is determined in step 950 that the checkpoint file should not be retained, If not, in step 970, checkpoints associated with the user application process The int file is deleted. In step 980, the cleanup subroutine 160 ends the execution. Checkpoint recovery application Bypassing software premature termination The User Application process allocates the resources needed to continue execution May be terminated on the way because it cannot be performed. Different from software failure If the process terminates prematurely due to a resource shortage or an exception, The process is still under control just prior to the end of the program. This Here, the exceptional state is a normal state defined by the user application process. Is defined as an execution other than a simple execution flow. Generally, resources that require processes When a process (for example, dynamic memory) cannot be allocated, Prints an error message indicating the "resource cannot be allocated" status and the program finish. Such software premature termination wastes a lot of useful processing Therefore, it is of course not preferable for an application that has been operating for a long time. General In addition, the process may start from the beginning, or perhaps, in a transparent checkpoint mode. Restart from the last checkpoint set at the interval specified in the Must. However, according to the checkpoint recovery system 10 according to the present invention, the process Inserts a checkpoint function call in the source code just before the end of It is possible to In this way, the process status will later correspond to the premature termination It can be restored to the point just before the position where it is performed. Furthermore, according to the invention, the user Execution controller after application process recovers to last checkpoint By using the function, the return value of the restoration subroutine 158 Can indicate that the current run is a recovery mode that initiates a special recovery process It is. In FIG. 10, for example, caused by a failure in allocating dynamic memory Source code containing the features of the present invention that can be used to bypass software premature termination Indicates the code segment. The code sequence shown in lines 1015 to 1050 is the first Executed at line 010 unless the process can allocate dynamic memory. The malloc function call executed at line 1010 is usually a C programming language related The memory allocation function in the library Allocate the start address of the allocated memory to the declared pointer ptr. Returns a value. For example, if another process runs out of remaining swap space When a process cannot allocate the desired dynamic memory, Seth is the variable MAX RETRY Until the maximum number of retries specified by COUNT is exceeded Retry the assignment. Note that the maximum number of retries is 0 Can also be set to MAX RETRY If COUNT is exceeded, step 102 After chkpnt () (checkpoint) is executed in step 5, the process is executed in step 1035. Ends. As noted above, when the process is restored, the restore subroutine 158 ( 8A and 8B) are called to check the volatile and persistent states for the last check. To a lockpoint (in other words, the checkpoint executed just before the end) I do. It should be noted that when executing the recovery subroutine 158, the program When the counter value is restored, execution returns from the restore subroutine 158 to the volatile status check. Jump to the checkpoint subroutine 154. The recovery subroutine 158 A positive return value indicating recovery mode to volatile state checkpoint subroutine 154 Return with. As described above, in the embodiment of FIG. Gram control proceeds to line 1040 which executes the recovery code. In this example, the recovery Mode is retry Reset count to 0 and retry allocation of desired dynamic memory It consists of doing. However, as will be apparent to those skilled in the art, execute other recovery code It is also possible. It should be noted that resource shortages can be transitional and pro- The same process runs under different conditions when the process is restored due to environmental changes As a result, the resource shortage state may be bypassed. However, resource shortage Is persistent, for example, if the current machine simply Bypass the premature termination if the resources provided are not sufficient to meet the Turn the process migration to another processing node with greater capacity. You may need an option. The technology of the present invention is a After starting on above, only after encountering a resource shortage condition It is possible to move a process to another machine with the desired resources. Bypass long initialization Many software programs include often time-consuming initialization routines. No. Furthermore, the same program is re-executed for different sets of input data. In each execution, it is necessary to repeat the time-consuming initialization routine in each execution. And many. However, in many cases, many executions of a processing routine are initialized with the same Can be reused with different input data. In this case, the initial Saves the activation state and changes depending on the future execution of the corresponding software program. Software programs by restoring them for use with force data sets. The efficiency of the system is greatly improved. According to a feature of the present invention, as shown in FIG. Checkpoints the initialization state associated with the ram and later uses different input data Can be restored to run against. Replace for each different run Input files are excluded from checkpoints and new input files are It is possible to process each new run. As shown in FIG. 11, an initialization bypass routine 1100 that bypasses a long initialization is executed. The process starts from step 1105. First, in step 1110, an initialization detour route 1100 includes, for example, a command line or a set of input file names. Read a first set of input parameters from the data file. Then, In step 1115, an initialization rule suitable for a given user application process is provided. Routine is executed. At step 1120, files to be excluded from checkpoints In other words, a file to be replaced in each subsequent execution is specified. Then, in step 1130, the volatile state and if not specified in the previous step The portion of the persistent state that was set is checkpointed. Checkpoint function When the control returns, at step 1135, the return value from the checkpoint function is 0. A test is performed to determine if the value is greater (indicating a recovery mode). Step If it is determined in step 1135 that the return value is greater than 0, this is the initialization bypass route. The first execution of the chin 1100, in step 1150, the initialization state and the first The first set of data is processed according to the input file and the set of parameters Is done. In step 1160, a set of input files and parameters to be further processed A test is performed to determine if there is an event. In step 1160, If it is determined that there is an input file and a set of parameters to process, Program control proceeds to step 1170, where the recovery subroutine 158 returns a positive return value. Be executed. The restoration subroutine 158 executes the check set in step 1130. Restore the process state to the point. It should be noted that step 113 The open file table that has been checkpointed at 0 It lists each input file associated with the cut. However, in subsequent runs, The same set of file descriptors listed in the open file table , Associated with the input file associated with each execution. Thus, the finger already As mentioned above, the recovery subroutine 158 is executed when the user opens the open file table. And a mechanism that allows the change to be reflected. Note that in step 1170, the process status is the last check When the point is restored, the program counter also corresponds to the checkpoint The program control is executed at step 1130. Jump to the checkpoint function to be performed. At step 1130, the program If you return from the checkpoint with a positive return value as described above, step 1 As a result of the test performed at 135, program control proceeds to step 1140. Thus, the next set of input parameters, including the list of input file names, is Without the need to re-run the optimization routine, To be read in step 1140. However, at step 1160, the input files and parameters to be further processed If it is determined that there is no data set, in step 1180, the initialization bypass routine 1 is executed. Execution of 100 ends. Memory reset Over time, undesired memory conditions can occur and the efficiency of software processes System performance and gradually degrade system performance until the software May cause failure. For example, software programs are often When the correct memory release is not performed for a certain execution path, including a successful commercial product In some cases, a memory leak may occur. The allocated memory space is As a result of the leak, it cannot be accessed because it is not referenced by any pointer. And cannot do it. Generally, a memory leak is caused by the first block of allocated memory. Pointer to the second block of allocated memory without releasing the first block. Happens when it is reassigned to point to As a result of memory leak, overall performance Processes run out of memory over time, with cumulative degradation and, in theory, over time You. In addition, memory keys provided by some commercial memory managers Caches and weak memory reuse mechanisms ensure that the machine has sufficient physical capacity to meet demand. Even with the quantity, a memory shortage condition may occur. For example, the user The application process repeatedly executes a small memory block (for example, 32 bytes). The memory manager requests those small blocks After freeing the memory, use another list or the memory cache to Manage future anticipated demands on locks. Thus, these small The smaller blocks become unavailable for larger memory requests. Small blocks If there were enough requests for If there is physical capacity, it will be rejected. What is a weak memory reuse mechanism? For example, a machine with 30 megabytes of memory might have a 15 megabyte memory, for example. It is about allocating a memory first and then releasing it. After that, When the user application process requests a 16 MB allocation, Run out of conditions. The reason is that 1 megabyte for every 15 megabytes released Rather than adding, this memory manager reserves 15 megabytes freed And try to allocate 16 megabytes. In this case, in practice, sufficient physical capacity Despite the amount, it seems to exceed the machine's memory limit. According to a feature of the present invention, the memory reset subroutine 1200 shown in FIG. Check the process memory in a “clean” state as part of the volatile state Process to prevent software failures. Roll back to a clean state. In step 1210, the memory reset subroutine The chin 1200 sets the loop index i to 0. Then step 1 At 215, an appropriate initialization routine is performed. It is important to note that initialized The dropped state is part of a volatile state that is checkpointed. Exclude all user files from checkpoint at step 1220 Is specified. Thus, when a checkpoint is set and later restored Only the clean memory state will be restored. In addition, all Exclude all input files from the checkpoint in a persistent state, in other words Thereby, the current contents of the user file are maintained after recovery. Step 1 At 230, execute the volatile state checkpoint subroutine 154 (FIG. 6). This will checkpoint the volatile state. Then step 1 At 240, based on the initialization state and the current value of loop index i, the desired Is executed. In step 1245, the process performed in the previous step is executed. The result of the logical task is written to the output buffer, as is well known. Output battery The contents of the file until the buffer is full or when the flush system call Until it is executed, it is not sent to its intended destination, such as a disk. At step 1250, whether there is a value of loop index i to be processed further A test is performed to determine if At step 1250, the rules to be further processed If it is determined that there is a value of the loop index i, in step 1255, the loop The index is incremented. Then, in step 1270, the loop Determines whether the current value of index i is a multiple of the specified reset period Test is performed. In other words, a clean memory state every 15 executions Current state of loop index is a multiple of 15 if state should be restored A test is performed to determine if At step 1270, the loop index is If it is determined that the current value of the box i is not a multiple of the specified reset period, Program control returns to step 1240 and continues processing as described above. However, at step 1270, the current value of loop index i is specified If it is determined that the output buffer is a multiple of the reset cycle, the output buffer After the keys are flushed, the memory is restored to a clean state. Then, In step 1280, the return value is made equal to the current value of the loop index i, and the recovery sub Executing routine 158 rolls back to a volatile state. Choi Since the lockpoint does not contain any user files, only the clean memory state is restored. Be old. As noted above, the recovery subroutine 158 includes a step 1230 Returns with the return value from the checkpoint function. Therefore, this return value (Equal to the index of the user application). The correct progress of the process is guaranteed. Recovery subroutine 158 is checkpoint Upon return from the function, program control proceeds to step 1240, and continues as described above. Continue. In step 1250, it is determined that there is no value of the loop index i to be further processed. If so, program control proceeds to step 1290, where memory reset subroutine is performed. The execution of the routine 1200 ends. As will be appreciated, the embodiments described herein and modifications thereof are merely exemplary of the invention. By way of illustration, those skilled in the art will appreciate that various modifications Various modifications can be implemented.

───────────────────────────────────────────────────── フロントページの続き (72)発明者フアン、イェンヌンアメリカ合衆国 08807 ニュージャージー、サマセットカウンティ、ブリッジウォーター、リンバーガードライヴ 33 (72)発明者キンタラ、チャンドラアメリカ合衆国 07059 ニュージャージー、サマセットカウンティ、ウォーレン、マウンテンアヴェニュー 29 (72)発明者ヴォー、キエム−フォンアメリカ合衆国 07922 ニュージャージー、ユニオンカウンティ、バークレーハイツ、スウェンソンサークル 80 (72)発明者ワン、イー−ミンアメリカ合衆国 07922 ニュージャージー、ユニオンカウンティ、バークレーハイツ、パインウッドクレセント 10────────────────────────────────────────────────── ─── Continuation of front page (72) Inventor Juan, Jen Nun United States 08807 New Jersey ー, Somerset County, Bridgewood Water, Limburger Drive 33 (72) Inventors Quintara, Chandra United States 07059 New Jersey ー, Somerset County, Wale , Mountain Avenue 29 (72) Inventors Vaud, Kiem-Fon United States 07922 New Jersey ー, Union County, Berkeley Heights, Swenson Circle 80 (72) Inventor One, E-Min United States 07922 New Jersey ー, Union County, Berkeley Heights, Pinewood Crescent 10

Claims

[Claims] 1. User application process running on a computer system In the method of checkpoint execution and recovery, The user application process determines from the volatile state and the user file And a process state comprising: The method comprises: (A) A step for performing a checkpoint of the volatile state at the checkpoint position And (B) Checkpoints that will monitor the persistent state and change the persistent state Detecting a file operation after the int position; (C) when the step b detects that the change of the persistent state is performed; Checkpoint at least the part of the persistence state that will be changed. Steps to perform; (D) By restoring the process state to the checkpoint position, Undoing any changes to the persistence state since the (E) Restart the execution of the user application process from the checkpoint position Opening the user application process. How to checkpoint and recover. 2. Checkpoint execution of volatile state is automatically and periodically invoked The method of claim 1, wherein: 3. The checkpoint execution of the volatile state is performed by the user application program. 2. The method of claim 1, wherein the method is called by a function call during a session. 4. Performing a persistent state checkpoint will change the persistent state Called by an interrupt routine that detects file operations The method of claim 1. 5. The method specifies a user file to be excluded from the checkpoint Further comprising the step of: Checkpoint execution of at least the part of the persistence state that will be changed The line is characterized by not including the specified excluded file checkpoint The method of claim 1 wherein: 6. Performing a checkpoint of a persistent state is not an option between volatile and persistent states. 2. The method of claim 1, wherein the method is not performed until a match occurs. 7. The part of the persistent state that is checkpointed is the intermediate state, The step (e) processes the input after the intermediate state. Item 1. The method of Item 1. 8. User application process running on a computer system In the method of checkpoint execution and recovery, The user application process determines from the volatile state and the user file And a process state comprising: The method comprises: (A) A step for performing a checkpoint of the volatile state at the checkpoint position And (B) For each change performed after the checkpoint position, the Checkpointing at least part of at least one user file And (C) By restoring the process state to the checkpoint position, Undoing changes to the user file since the lockpoint location When, (D) Restart the execution of the user application process from the checkpoint position Opening the user application process. How to checkpoint and recover. 9. Checkpoint execution of volatile state is automatically and periodically invoked The method of claim 8, wherein: 10. Checkpoint execution of the volatile state is performed by the user application program. 9. The method of claim 8, wherein the method is invoked by an instruction in the process. 11. Check at least part of at least one user file to be modified Executing a checkpoint detects a file operation that changes one of the user files. 9. The method of claim 8, wherein the method is called by an issued interrupt routine. 12. The method specifies a user file to be excluded from the checkpoint. Further comprising the step of defining Checkpoint at least part of at least one user file to be modified Must not include checkpoints for the specified excluded files 9. The method of claim 8, wherein: 13. Check at least part of at least one user file to be modified Executes the run until the inconsistency between the volatile state and the user file occurs. 9. The method of claim 8, wherein said method is not performed. 14． The checkpointed part of the user file is in the intermediate state. And The step (d) processes an input after the intermediate state. Item 8. The method according to Item 8. 15. The method for restoring the initialization state associated with the user application process And A user application process has a process state and has at least two Perform processing tasks based on the initialization state of the The method comprises: (A) A process for initializing a user application process to form an initialized state Tep, (B) Specify the input file to be excluded from the process state checkpoint Steps (C) Checkpointing a part of the process state that is not excluded Steps and (D) a processing status based on the initialization state and the current set of input files; Performing the task, (E) Put the user application process in a state where the checkpoint has been executed Recovering and generating a predefined return value indicating the recovery mode; (F) If step e returns the predefined return value, a new Steps to take a set of input files and replace the excluded input files And (G) Repeat steps d to f for each set of input files to be processed. The first step in the user application process, which is characterized by How to recover the reset state. 16. The process state includes a volatile state and a persistent state, The step c includes: Performing a checkpoint of the volatile state; Checkpoint that will monitor the persistence state and change the persistence state A monitor step for detecting file operations after the position; If the monitoring step detects that a change in the persistent state is performed, Checkpoint at least the part of the persistence state that will change 16. The method of claim 15, comprising the steps of: