(57)【要約】【課題】本発明の目的は、例外の監視と処理を容易におこなうためのプログラムを提供することにある。【解決手段】本発明のプログラム１０は、例外監視機能１４、ダンプ機能１６、およびダンプファイル４４の表示機能１８を有する。例外監視機能１４によってダンプをおこなうか否かの選択をおこない、ダンプ機能１６によってダンプファイル４４の内容の選択をおこない、表示する機能１８によってダンプファイル４４をわかりやすいように表示する。【選択図】  図１
2008186378.tif 000002
【特許請求の範囲】
【請求項１】
Java VM、機能セット、フレームワーク、アプリケーションを記憶する記憶手段を有するコンピュータシステムにおいて、機能セット、フレームワーク、アプリケーションのいずれかでデータを処理するときに発生する例外に対処するためのプログラムであって、
コンピュータシステムを、
前記Java VMによって全ての例外のスーパークラスがJava VMのヒープにロードされるときに、該スーパークラスのコンストラクタに例外監視手段を呼び出す機能を埋め込む手段、
少なくとも例外を監視するクラスまたはスーパークラスを記述したコンフィグファイル、
前記コンストラクタがスタックにロードされ後、該コンストラクタが動作したときに前記呼び出す機能によって呼び出される前記例外監視手段であり、Java VMのスタックに格納されたメソッドのクラスまたはスーパークラスがコンフィグファイルに記述されたクラスまたはスーパークラスに含まれるか否かをチェックする例外監視手段、
前記チェックによって、スタックに格納されたメソッドを有するクラスまたはスーパークラスがコンフィグファイルに記述されたクラスまたはスーパークラスに含まれた場合、Java VMのヒープからオブジェクトを取得し、該オブジェクトをダンプする手段、
として機能させるプログラム。
【請求項２】
監視する例外の発生経路の記述としてメソッドのシグネチャおよびクラスパスを前記コンフィグファイルに含み、
前記例外監視手段が、スタックに格納されたメソッドのシグネチャおよびクラスパスが前記コンフィグファイルに記述された発生経路に含まれるか否かをチェックし、
前記チェックによって、スタックに格納されたメソッドのシグネチャおよびクラスパスが前記コンフィグファイルに記述された発生経路に含まれた場合、前記ダンプする手段が、ヒープからオブジェクトを取得し、該オブジェクトをダンプする、
請求項１のプログラム。
【請求項３】
前記コンフィグファイルの記述が前記Java VMの起動後に追加または変更できるように、該コンフィグファイルをテキストファイルで構成し、実行ファイルである例外監視手段とは分離する請求項１または２のプログラム。
【請求項４】
前記ダンプする手段が、
例外発生時に、スタックに格納されたメソッドのデータを取得する手段と、
ダンプの対象とするオブジェクトに関するデータを記述したオブジェクト・プールと、
オブジェクトごとにダンプ時に必要なフィールドを記述したテンプレートと、
スタックから取得したデータがオブジェクトである場合に、オブジェクト・プールに記述されたオブジェクトであるか否かをチェックする手段と、
スタックから取得したデータがオブジェクトであり、該オブジェクトがオブジェクト・プールに記述されている場合、該オブジェクトのテンプレートの有無をチェックし、あればテンプレートを取得する手段と、
前記オブジェクトのテンプレートを取得した場合、Java VMのヒープから該当するオブジェクトのテンプレートに記述されていないフィールドを削除しながら該オブジェクトを取得する手段と、
不要なフィールドを削除しながら取得したオブジェクトのダンプファイルを生成する手段と、
を含む請求項１乃至３のいずれかのプログラム。
【請求項５】
前記オブジェクトのテンプレートがない場合、前記オブジェクトを取得する手段が、前記ヒープからフィールドの削除をおこなわずにオブジェクトを取得し、前記ダンプファイルを生成する手段が、取得したオブジェクトのダンプフィルを生成する請求項４のプログラム。
【請求項６】
前記ダンプファイルを生成する手段が、前記スタックに格納されたメソッドから取得した例外発生時のデータも含めてダンプファイルを生成する請求項４または５のプログラム。
【請求項７】
コンピュータシステムのモニターにダンプファイルを表示するために、
前記ダンプファイルに含まれる例外発生時のメソッドのデータを表示する手段と、
前記メソッドのデータがオブジェクトである場合、ダンプファイルの該オブジェクトのデータを表示する手段と、
を含むスタックビューアを有する請求項６のプログラム。
【請求項８】
前記メソッドのデータには、メソッドごとにメソッド名、thisオブジェクトのデータ、メソッドのシグネチャおよび実行ラインのデータが含まれ、前記モニターに表示されたメソッド名がコンピュータシステムのポインタで選択された場合、
選択されたメソッド名に対応するメソッドのデータを前記スタックビューアから受け取り、受け取った該メソッドのデータに対応する前記アプリケーションを取得し、表示するソースビューアと、
選択されたメソッド名に対応するthisオブジェクトのデータを前記スタックビューアから受け取り、受け取ったthisオブジェクトのデータに対応するオブジェクトのデータを前記ダンプファイルから取得し、表示するオブジェクトビューアと、
選択されたメソッド名に対応するthisオブジェクトのデータおよびメソッドのシグネチャを前記スタックビューアから受け取り、受け取ったthisオブジェクトのデータおよびメソッドのシグネチャに対応するメソッドからローカル変数のデータを取得し、表示するローカル変数ビューアと、
を含む請求項７のプログラム。
【請求項９】
前記アプリケーション、機能セット、フレームワークがJavaソースまたはバイトコードであり、前記ソースビューアが、前記thisオブジェクトのデータに対応するJavaソースを取得し、Javaソースがなければthisオブジェクトのデータとメソッドのシグネチャに対応するバイトコードを取得し、前記実行ラインのデータに基づいて取得したJavaソースまたはバイトコードの該当実行ラインを他の実行ラインとは区別するようにモニターで表示する請求項８のプログラム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション（application software）でデータを処理したときに起きる例外（exception）に対処するためのプログラムに関するものである。
【背景技術】
【０００２】
オブジェクト指向のプログラミング言語としてＪａｖａ（登録商標、以下省略）が周知である。従来のコンピュータシステムにおけるアプリケーション開発環境は、図７に示すように、階層構造となっている。Ｊａｖａ  ＶＭ（virtual machine）が、オペレーティング・システムとアプリケーションの間に入る。Ｊａｖａのアプリケーションはプラットフォーム（platform）に依存しないバイトコード（byte code）で提供されている。Ｊａｖａ  ＶＭは、アプリケーションをプラットフォームに固有のネイティブコード（native code）に変換する。
【０００３】
アプリケーション開発環境には、複数のモジュール化されたＪａｖａプログラムを含む機能セットが用意される。機能セットの中にはＪ２ＳＥ（Java 2 Standard Edition）やＪ２ＥＥ（Java 2 Enterprise Edition）と呼ばれるものがある。アプリケーションは、自身の有するクラス（class）でデータを処理する以外に、機能セットのクラスを使用する場合もある。また、アプリケーションはフレームワーク（framework）を使用する場合もあり、汎用および専用のフレームワークがある。アプリケーションが機能セットのクラスにデータを転送する場合、図８のように、アプリケーションから、専用フレームワーク、汎用フレームワーク、機能セットの順番にリレー形式で転送される場合がある。これは、あるオブジェクトのメソッド（method）の引数などが他のクラスやオブジェクト（object）である場合、その引数となっているオブジェクトやクラスを呼び出す（call）ためである。
【０００４】
図８に示すように、機能セットは複数のクラスが含まれる。例えば、Ｊ２ＳＥであれば約４０００のクラス、Ｊ２ＥＥであれば約２０００のクラスがある。アプリケーションによってフレームワークの数も増える場合がある。アプリケーションの開発で意識しながら使用するフレームワークが数個であったとしても、そのフレームワークが他の機能セットやフレームワークを使用する場合もある。したがって、アプリケーションの開発時に、アプリケーションが使用する機能セットおよびフレームワークの全てのクラスを把握するのは困難である。アプリケーションにバグが含まれる危険性が高まる。アプリケーションにバグが含まれると、アプリケーション実行時に例外が発生し、アプリケーションは異常終了する。場合によってはコンピュータシステム自体がシステムダウンしてしまう。
【０００５】
例外が発生するとアプリケーションは異常終了してしまうが、"catch"などを利用して例外処理をしておくと異常終了を防ぐことができる。アプリケーションの開発時に発生した例外の解析をおこない、例外処理をおこなう。例外を解析するためにスタック・トレースやログをダンプ（dump）し、それを利用する。
【０００６】
スタック・トレースなどは、例外発生の箇所および発生までの処理の流れの情報を有する。しかし、スタック・トレースの情報を基に、例外発生時の環境と同じ環境で例外が発生することを確認するため、非常に手間がかかる。スタック・トレースには、例外を引き起こしたデータと例外発生までのデータの流れの情報はない。複数の例外処理をおこなった場合、間違った例外処理があると、スタック・トレースで情報が得られない場合もある。
【０００７】
そこで、例外発生時にデータの流れを把握するために、各メソッドに引数のログが追加される。しかし、あるメソッドが他のメソッドを呼び出すとログのデータ量が大きくなる。ログのデータ量が大きくなると、システムのCPUやIOに大きなオーバーヘッドが発生する。システムに負荷がかかりすぎて、実際に使用するのが難しい。自ら構築したアプリケーションの部分以外ではログを取ることができない場合がある。引数だけではデータの流れを全て把握するのが難しい。
【０００８】
例外処理により監視対象の例外を指定するシステムがある。しかし、コンピュータ・システムの再起動が必要であり、速やかに例外の追加や変更を行うことができない。
【０００９】
非特許文献１に、例外対策が記載されている。コンピュータシステムがシステムダウンしてしまった場合、その再現をおこなったりしながら、どこに例外があるかの検討を行う。更に、ログを活用しながら例外を突き止め、例外処理をおこなう必要がある。しかし、上述したように、ログの量が多くなると例外の解析も苦労する。例外処理の経験を積んでいないと例外処理がはかどらない場合も多い。
【００１０】
【非特許文献１】Java Press Vol.46  pp.168-181  （株）技術評論社  平成１８年２月１５日発行
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、例外の監視と処理を容易におこなうためのプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
本発明のプログラムは、Java VM、機能セット、フレームワーク、アプリケーションを記憶する記憶手段を有するコンピュータシステムにおいて、機能セット、フレームワーク、アプリケーションのいずれかでデータを処理するときに発生する例外に対処するためのプログラムである。本発明のプログラムは、例外に対処するために、例外の監視機能、例外発生時のダンプ機能、およびダンプファイルの表示機能を有する。
【００１３】
例外を監視するために、Java VMの起動時に、全ての例外のスーパークラスのコンストラクタに例外監視手段を呼び出す機能を埋め込む手段、少なくとも例外を監視するクラスまたはスーパークラスを記述したコンフィグファイル、前記コンストラクタが動作したときに前記呼び出す機能によって呼び出される前記例外監視手段であり、コンピュータシステムのスタックに格納されたメソッドのクラスまたはスーパークラスがコンフィグファイルに記述されたクラスまたはスーパークラスに含まれるか否かをチェックする例外監視手段、前記チェックによって、コンピュータシステムのスタックに格納されたメソッドを有するクラスまたはスーパークラスがコンフィグファイルに記述されたクラスまたはスーパークラスに含まれた場合、Java VMのヒープからオブジェクトを取得し、該オブジェクトをダンプする手段、としてコンピュータシステムを機能させる。
【００１４】
コンピュータシステムの起動後に、Ｊａｖａ  ＶＭを起動させる。Ｊａｖａ  ＶＭによって、ヒープにThrowableも一旦格納される。ヒープにThrowableを格納するとき、上記埋め込む手段がThrowableのコンストラクタに例外監視手段を呼び出す機能を埋め込む。例外が発生する場合、アプリケーションの動作により、Ｊａｖａ  ＶＭがThrowableをスタックに格納する。例外が発生すると、Throwableが全ての例外のスーパークラスになっているため、Throwableのコンストラクタが実行され、例外監視手段を起動させる。例外監視手段が、例外発生時のスタックに格納された全てのメソッドのクラスまたはスーパークラスがコンフィグファイルに記述されているかをチェックする。チェックでクラスまたはスーパークラスがコンフィグファイルに記述されたいる場合、ダンプする手段が、ヒープからオブジェクトを取得し、オブジェクトをダンプする。
【００１５】
前記ダンプする手段は、例外発生時に、スタックに格納されたメソッドのデータを取得する手段と、ダンプの対象となるオブジェクトに関するデータのオブジェクト名を記述したオブジェクト・プールと、オブジェクトごとにダンプ時に必要なフィールドを記述したテンプレートと、スタックから取得したデータがオブジェクトである場合に、オブジェクト・プールに記述されたオブジェクトであるか否かをチェックする手段と、スタックから取得したデータがオブジェクトであり、該オブジェクトがオブジェクト・プールに記述されていない場合、該オブジェクトのテンプレートの有無をチェックし、あればテンプレートを取得する手段と、前記オブジェクトのテンプレートを取得した場合、コンピュータシステムのヒープから該当するオブジェクトのテンプレートに記述されていないフィールドを削除しながら該オブジェクトを取得する手段と、不要なフィールドを削除しながら取得したオブジェクトのダンプファイルを生成する手段と、を含む。
【００１６】
データを取得する手段が、スタックに格納されたメソッドから例外発生時のデータを取得する。取得したデータがオブジェクトである場合、オブジェクト・プールにあるか否かをチェックする。取得したデータがオブジェクトでなければ、以降の処理はおこなわない。オブジェクト・プールにはダンプの必要のないオブジェクトの情報がある。チェックによってオブジェクトがあれば、以降の処理はおこなわない。取得したオブジェクトのテンプレートを参照する。テンプレートがあれば、テンプレートに記載された必要なフィールドのみをヒープに格納されたオブジェクトから取得する。取得したオブジェクトからダンプファイルを生成する。
【００１７】
コンピュータシステムのモニターにダンプファイルを表示するために、前記ダンプファイルに含まれる例外発生時のメソッドのデータを表示する手段と、前記メソッドのデータがオブジェクトである場合、ダンプファイルの該オブジェクトのデータを表示する手段と、を含むスタックビューアを有する。
【００１８】
データを取得する手段が、スタックに格納されたメソッドから例外発生時のデータを取得する。取得したデータがオブジェクトである場合、オブジェクト・プールにあるか否かをチェックする。取得したデータがオブジェクトでなければ、以降の処理はおこなわない。
【発明の効果】
【００１９】
本発明によると、ダンプ機能を動作させる前に、ダンプをおこなうか否かの選択をおこなっている。全ての例外発生時にダンプをおこなうことはない。コンピュータシステムへの負荷が低減される。不必要にダンプがおこなわれないので、所望の例外解析のみをおこなうことができる。
【００２０】
本発明は、必要なフィールドのみをダンプできるようになっている。不要なオーバーヘッドを削除することができ、ダンプ時にコンピュータシステムへの負荷が低減される。また、ダンプファイルのデータ量も少なくすることができるため、例外の解析も容易になる。
【００２１】
本発明は、例外解析をおこないやすくするために、ダンプファイルから所望の項目を取得してモニターに表示する。表示されたメソッドをマウスなどのポインターで選択することにより、そのメソッドに関連したアプリケーション、フレームワーク、機能セットのJavaソースまたはバイトコード、オブジェクト、およびローカル変数を表示するため、単にダンプファイルを表示するのと比べて例外解析がおこないやすくなっている。
【発明を実施するための最良の形態】
【００２２】
本発明に係るプログラムについて図面を用いて説明する。プログラムは、Ｊａｖａのアプリケーション開発時の例外処理のためのものである。
【００２３】
図１に示すＪａｖａのアプリケーション開発環境は、ＣＰＵなどのハードウェハは省略されている。本発明のプログラム１０を使用するコンピュータシステム１２として、サーバーが挙げられる。図１では、ハードディスクやメモリなどの記憶手段に記憶されたプログラムを示している。Ｊａｖａ  ＶＭ１０６、機能セット１０８、フレームワーク１１４、アプリケーション１０４については、従来技術と同じであるので説明を省略する。
【００２４】
本発明のプログラム１０は、例外監視機能１４、ダンプ機能１６、およびダンプファイル４４の表示機能１８を有する。例外監視機能１４によってダンプをおこなうか否かの選択をおこない、ダンプ機能１６によってダンプファイル４４の内容の選択をおこない、表示する機能１８によってダンプファイル４４をわかりやすいように表示する。まずは例外監視機能１４について説明する。
【実施例１】
【００２５】
本発明のプログラム１０は、図２に示すように、Ｊａｖａ  ＶＭによってヒープ（heap）に全ての例外のスーパークラスがロードされるとき、そのスーパークラスのコンストラクタ（constructor）に例外監視手段２６を呼び出す機能を埋め込む手段２２、少なくとも例外を監視するクラスまたはスーパークラスを記述したコンフィグファイル２４、コンストラクタが動作したときに前記呼び出す機能によって呼び出される例外監視手段２６であり、コンピュータシステム１２のスタック（stack）２０に格納されたメソッドのクラスまたはスーパークラスがコンフィグファイル２４に記述されたクラスまたはスーパークラスに含まれるか否かをチェックする例外監視手段２６、チェックによって、コンピュータシステム１２のスタック２０に格納されたメソッドを有するクラスまたはスーパークラスがコンフィグファイル２４に記述されたクラスまたはスーパークラスに含まれた場合、Ｊａｖａ  ＶＭのヒープからオブジェクトを取得し、オブジェクトをダンプする手段２８、としてコンピュータシステム１２を機能させる。
【００２６】
上記の埋め込む手段２２は、Ｊａｖａ  ＶＭ１０６が起動し、ヒープに全てのメソッドやオブジェクトをロードするときに、Throwableに例外監視手段を呼び出す機能を埋め込む。Throwableは全ての例外のスーパークラスであり、どの例外発生時にも動作するものである。実際に例外が発生するのはサブクラスである。例外監視手段２６を呼び出す機能は、ＢＣＩ（byte code instructions）で提供される。例外発生時にＢＣＩが実行される。Ｊａｖａ  ＶＭ１０６が起動するのはコンピュータシステム１２の起動後である。アプリケーションが実行されると、Ｊａｖａ  ＶＭ１０６によって必要なメソッドがヒープからスタック２０にロードされる。例外が発生する場合、Throwableのコンストラクタはスタックに格納される。
【００２７】
本発明は、例外を監視するクラスなどを記述したコンフィグファイル２４を設けている。プログラマーが監視を行いたい例外をコンフィグファイル２４に記述する。全ての例外を監視することにはならず、コンピュータシステム１２に負担をかけることはない。
【００２８】
例外監視手段２６は、例外が発生するまでは動作しない。したがって、コンピュータシステム１２への負荷を少なくしている。例外発生時にスタック２０に格納されているメソッドのクラスまたはスーパークラスがコンフィグファイル２４に記述されていなければ、例外監視手段２６は動作を終了する。以降の処理は実行されず、不必要なダンプファイル４４を生成することはない。なお、クラスはメソッドとフィールド（field）をまとめたオブジェクトを生成するための型であり、メソッドはスタック２０と呼ばれる記憶領域に格納される。メソッドは、Ｊａｖａ  ＶＭ１０６によってスタック２０への格納と削除がおこなわれる。
【００２９】
ダンプする手段２８は、ヒープから取得したオブジェクトからダンプファイル４４を生成するものである。取得されるオブジェクトは、例外発生時にスタック２０に格納されていたメソッドに関連するものである。例えば、メソッドの引数、ローカル変数、thisオブジェクトなどがオブジェクトとなる場合、そのオブジェクトがヒープから取得される。言い換えると、メソッドがオブジェクトを使用する場合、そのオブジェクトがヒープから取得される。ダンプファイル４４は例外処理をおこなうために使用される。ヒープはオブジェクトを格納する記憶領域であり、Ｊａｖａ  ＶＭ１０６によって、オブジェクトの格納と削除がおこなわれる。thisオブジェクトは引数や変数にthisを使用したオブジェクトを指す。スタック２０とヒープは、Ｊａｖａ  ＶＭによって管理される記憶領域である。
【００３０】
本発明のプログラム１０の動作について説明する。（１）コンピュータシステム１２が起動後、Ｊａｖａ  ＶＭ１０６が起動される。Ｊａｖａ  ＶＭ１０６によって、ヒープにThrowableも格納される。ヒープにThrowableを格納するとき、上記の埋め込む手段２２がThrowableのコンストラクタに例外監視手段２６を呼び出す機能を埋め込む。この例外監視手段２２を呼び出す機能はＢＣＩで提供される。アプリケーションが実行されると、Ｊａｖａ  ＶＭ１０６によってスタック２０にメソッドがロードされる。例外が発生する場合、Throwableのコンストラクタはスタックに格納される。
【００３１】
（２）例外が発生すると、Throwableが全ての例外のスーパークラスになっているため、Throwableのコンストラクタが実行される。コンストラクタが実行されることにより、上記（１）で埋め込んだＢＣＩが起動し、例外監視手段２６を起動させる。
【００３２】
（３）例外監視手段２６が、例外発生時のスタック２０に格納された全てのメソッドのクラスまたはスーパークラスがコンフィグファイル２４に記述されているかをチェックする。無ければ例外の監視を終了し、以降の処理はおこなわない。
【００３３】
（４）上記（３）のチェックでクラスまたはスーパークラスがコンフィグファイル２４に記述されている場合、ダンプする手段２８が、ヒープからオブジェクトを取得し、このオブジェクトをダンプする。ヒープから取得するオブジェクトは、スタック２０から取得されたデータに関するものである。例えば、スタックから取得されたメソッドの引数、ローカル変数、thisオブジェクトなどがオブジェクトとなる場合、そのオブジェクトがヒープから取得される。
【００３４】
本発明は、上述したように、例外発生時に所望のオブジェクトのみがダンプされるので、従来に比べてダンプするデータ量が減る。ダンプする時間も短縮され、コンピュータシステム１２への負荷が低減される。例えば、従来であれば１０分近くかかっていたダンプが、数秒で終了する場合もある。所望のオブジェクトのみがダンプされるため、例外の解析も容易になり、例外処理の間違いも減る。
【実施例２】
【００３５】
アプリケーション１０４によってはデータの転送経路が多くなったり、複雑になったりすることがある。全ての転送経路のメソッドに対してオブジェクトを取得し、ダンプすることは、コンピュータシステム１２への負荷が大きくなる場合がある。したがって、所望の経路で発生する例外に対してダンプができるようにしても良い。メソッドが他のメソッドをコールする経路が複数ある場合に、所望の経路の例外を監視することができる。この場合、上述したプログラム１０に、以下の構成を付加する。
【００３６】
コンフィグファイル２４に監視する例外の発生経路の記述を加える。例外監視手段２６は、例外発生時に、スタック２０に格納されたメソッドのシグネチャおよびクラスパスがコンフィグファイル２４に記述された発生経路に含まれるか否かをチェックする。ダンプする手段２８は、チェックによって、スタック２０に格納されたメソッドのシグネチャまたはクラスパスがコンフィグファイル２４に記述された発生経路に含まれた場合、コンピュータシステム１２のヒープからオブジェクトを取得し、そのオブジェクトをダンプする。シグネチャは、引数のタイプ（クラス名）と戻り値のタイプ（クラス名）を定義するものである。
【００３７】
上記の構成により、監視したい経路の例外をダンプし、他の経路で例外が発生してもダンプはおこなわれなくなる。例えば、図３に示すように、第１および第２経路を有する場合、第１経路のみを監視することができる。同じ場所で例外が発生しても、データの処理が第２経路であればダンプされない。必要な経路のデータのみをダンプすることができ、コンピュータシステム１２の負荷を押さえることができる。
【００３８】
なお、コンフィグファイル２４の記述は、実施例１または実施例２のいずれかの内容であっても良いし、両方であっても良い。両方である場合、実施例１および実施例２で説明した記載がコンフィグファイル２４に記載されていた場合に、ヒープからオブジェクトを取得してダンプをおこなう。
【実施例３】
【００３９】
コンフィグファイル２４の記述を柔軟に変更できればコンピュータシステム１２の運用が楽になる。そのために、コンフィグファイル２４の記述が、Ｊａｖａ  ＶＭ１０６の起動後に追加または変更されるようにする。コンフィグファイル２４を実行ファイルである例外監視手段２６から分離したテキストファイルにし、例外監視手段２６が常に動作していても、Ｊａｖａ  ＶＭ１０６の起動後のコンフィグファイル２４の変更が可能となる。
【００４０】
実施例１から３に示したように、本発明は従来と比較してダンプファイル４４のデータ量を少なくすることができる構成となっている。また、柔軟にダンプする内容を変更できる構成になっている。ダンプする内容も所望のデータのみをダンプすることができ、例外処理の負担を減らすことができる。コンピュータシステム１２の運用が容易となっている。
【実施例４】
【００４１】
次に、ダンプ機能１６、すなわち実施例１で示したダンプする手段２８について説明する。ダンプする手段２８は、図４に示すように、スタック２０に格納されたメソッドから例外発生時のデータを取得する手段３０と、ダンプの対象となるオブジェクトに関するデータを記述したオブジェクト・プール３２と、オブジェクトごとにダンプ時に必要なフィールドを記述したテンプレート３４と、スタック２０から取得したデータがオブジェクトである場合に、オブジェクト・プール３２に記述されたオブジェクトであるか否かをチェックする手段３６と、スタック２０から取得したデータがオブジェクトであり、そのオブジェクトがオブジェクト・プール３２に記述されている場合、オブジェクトのテンプレート３４の有無をチェックし、あればテンプレート３４を取得する手段３８と、オブジェクトのテンプレート３４を取得した場合、ヒープ４０から該当するオブジェクトのテンプレート３４に記述されていないフィールドを削除しながらオブジェクトを取得する手段４２と、不要なフィールドを削除しながら取得したオブジェクトのダンプファイル４４を生成する手段４６と、を含む。
【００４２】
スタック２０の例外発生時のデータとしては、メソッドの名前、メソッドのシグネチャ、引数のデータ、ローカル変数のデータ、thisオブジェクトのデータ、実行ラインなどである。引数のデータは、タイプ（クラス名）、名前、値もしくはオブジェクトＩＤを含む。ローカル変数のデータは、タイプ（クラス名）、名前、値もしくはオブジェクトＩＤを含む。thisオブジェクトのデータは、クラス名およびオブジェクトＩＤを含む。
【００４３】
オブジェクト・プール３２に格納されるオブジェクトに関するデータのは、少なくともオブジェクト名が必要であるが、他のデータを含んでも良い。例えば、オブジェクトのＩＤ、オブジェクトのタイプ（クラス名）、インスタンス（instance）となるオブジェクトのＩＤ、フィールドの情報などである。フィールドの情報としては、クラス名、名前、値もしくはオブジェクトのＩＤなどである。
【００４４】
チェックする手段３６は、上述した例外発生時のデータ、例えば引数などがオブジェクトとなっている場合、オブジェクト・プール３２を参照する。このデータが、オブジェクト・プール３２に無ければ以降の処理はおこなわず、あればテンプレート３４を使用したダンプをおこなう場合がある。言い換えると、例外発生時にスタック２０から取得したデータがオブジェクトでないと、ダンプはおこなわれない。また、所望のオブジェクトでなければ、ダンプをおこなわない。
【００４５】
テンプレートを取得する手段３８は、ダンプをおこなうオブジェクトのテンプレート３４を取得する。テンプレート３４には、ダンプに必要な情報が記述されている。この情報としては、ダンプをおこなうオブジェクトのフィールドが含まれる。テンプレート３４は、Ｊａｖａ  ＶＭ１０６が起動後であっても変更可能なように、テキストファイルで作成し、他の実行ファイルとは分離するようにする。
【００４６】
オブジェクトを取得する手段４２は、テンプレート３４を使用して不必要なフィールドを削除しながらヒープ４０にロードされたオブジェクトのデータを取得する。テンプレートによってオブジェクトにフィルターをかけることとなっている。したがって、取得するオブジェクトのデータ量が減少され、コンピュータシステム１２への負荷が低減される。不必要なフィールドのデータがダンプされないので例外の解析も楽になる。オブジェクトのデータとしては、オブジェクトのＩＤ、タイプ（クラス名）、インスタンスとなるオブジェクトのＩＤ、フィールドのデータである。この中で、フィルターがかけられるのがフィールドである。不必要なフィールドはダンプの対象とはならない。フィールドのデータとしては、タイプ（クラス名）、名前、値もしくはオブジェクトのＩＤが含まれる。なお、テンプレート３４を取得する手段とオブジェクトを取得する手段は、一体であっても良い。
【００４７】
実施例４における本発明のプログラム１０の動作を説明する。（１）上記のデータを取得する手段３０が、スタック２０に格納されたメソッドから例外発生時のデータを取得する。取得するデータは、上述したようなデータである。ローカル変数などは、オブジェクトである場合がある。
【００４８】
（２）取得したデータがオブジェクトである場合、オブジェクト・プール３２にあるか否かをチェックする。取得したデータがオブジェクトでなければ、以降の処理はおこなわない。オブジェクト・プール３２にはダンプをおこなうオブジェクトの情報がある。チェックによってオブジェクトが無ければ、以降の処理はおこなわない。したがって、取得したデータがオブジェクトであって、オブジェクト・プール３２に情報がある場合、以降の処理をおこなう。不要なダンプをおこなわず、コンピュータシステム１２に負荷をかけない。
【００４９】
（３）取得したデータがオブジェクトであって、オブジェクト・プール３２に情報がある場合、テンプレート３４を参照する。テンプレート３４はダンプに必要なデータが含まれており、下記（４）で取得するオブジェクトにフィルターをかけるものである。
【００５０】
（４）テンプレート３４があれば、テンプレート３４に記載された必要なフィールドのみをヒープ４０に格納されたオブジェクトから取得する。オブジェクトは、スタック２０から取得したデータに対応したものである。不要なフィールドを削除しながらオブジェクトを取得するため、オブジェクトのデータ量が低減される。
【００５１】
ヒープ４０から取得したオブジェクトのデータが、オブジェクトである場合がある。すなわち、あるオブジェクトが他のオブジェクトを継承している場合である。そこで、ヒープ４０からデータを取得した後、そのデータに対して（２）から（４）の工程を行う。（２）から（４）の工程は、１度の場合もあれば複数回繰り返される場合もある。
【００５２】
（５）ヒープ４０から取得したオブジェクトのデータからダンプファイル４４を生成する。すなわち、取得したオブジェクトをダンプする。（２）から（４）の作業を繰り返しおこなう場合があるが、そのような場合は、ヒープ４０から取得したデータの全てをダンプするようにする。
【００５３】
以上のように、本発明は不要なダンプをおこなわなかったり、ダンプファイル４４のデータ量を低減することができる。したがって、コンピュータシステム１２への負荷が低減される。また、例外の解析の苦労も低減される。
【００５４】
オブジェクト・プール３２に記述されるのは、ダンプされるオブジェクトに関するものであるが、その逆であっても良い。ダンプをおこなわないオブジェクトについて、オブジェクト・プール３２を作成しても良い。チェックする手段３６の動作は逆になる。
【実施例５】
【００５５】
オブジェクトの全てについてテンプレート３４を作成する必要はない。例えば、あるオブジェクトの全てのフィールドをダンプしたい場合である。したがって、オブジェクトのテンプレートがない場合、オブジェクトを取得する手段４２が、ヒープ４０からフィールドの削除をおこなわずにオブジェクトを取得しするように構成する。また、ダンプファイル４４を生成する手段４６は、フィールドの削除をおこなわずに取得したオブジェクトのダンプフィル４４を生成する。
【００５６】
フィールドの削除をおこなうオブジェクトのみに対してテンプレート３４を作成すればよい。テンプレート３４のデータ量を減らすことができ、テンプレート３４の作成も簡単になる。
【実施例６】
【００５７】
ダンプファイル４４に含まれるのがオブジェクトだけではなくスタック・トレースに関しても必要となる場合がある。その場合のために、ダンプファイル４４を生成する手段は、スタックに格納されたメソッドから取得した例外発生時のデータも含めてダンプファイル４４を生成するようにする。
【００５８】
実施例４から６で示したように、本発明は、ダンプについてもコンピュータシステム１２への負荷を低減させ、例外の解析を容易にするように構成されている。
【実施例７】
【００５９】
例外の解析をおこなうためにダンプファイル４４を実際にコンピュータシステム１２のモニターに表示させることが必要である。例外の解析をしやすくするために、ダンプファイル４４の項目を分けて表示するのが好ましい。本発明では、図５に示すようにスタックビューア４８、ソースビューア５０、オブジェクトビューア５２、およびローカル変数ビューア５４とを含むように構成する。コンピュータシステム１２はＧＵＩ（graphical user interface）に対応したものが好ましい。
【００６０】
スタックビューア４８は、ダンプファイル４４に含まれる例外発生時のメソッドのデータを表示する手段と、メソッドのデータがオブジェクトである場合、ダンプファイル４４にあるそのオブジェクトのデータを表示する手段と、を含む。ここで、ダンプファイル４４は実施例４などで取得したものである。
【００６１】
ダンプファイル４４に含まれるメソッドのデータは、例外発生時にスタック２０に格納されていたメソッドに関するデータである。具体的には、メソッドのデータには、メソッドの名前、メソッドのシグネチャ、引数のデータ、ローカル変数のデータ、thisオブジェクトのデータ、実行ラインなどである。引数のデータは、タイプ（クラス名）、名前、値もしくはオブジェクトＩＤを含む。ローカル変数のデータは、タイプ（クラス名）、名前、値もしくはオブジェクトＩＤを含む。thisオブジェクトのデータは、クラス名およびオブジェクトＩＤを含む。ダンプの対象となるメソッドが複数になれば、メソッドごとにデータが存在する。
【００６２】
メソッドのデータ、すなわちメソッドの引数などがオブジェクトである場合、該当するオブジェクトのデータもあわせて表示する。表示されるオブジェクトのデータは、ダンプファイル４４のためにヒープ４０から取得されたものである。オブジェクトのデータとしては、オブジェクトのＩＤ、タイプ（クラス名）、インスタンスとなるオブジェクトのＩＤ、フィールドのデータである。この中で、フィルターがかけられるのがフィールドである。不必要なフィールドはダンプの対象とはならない。フィールドのデータとしては、タイプ（クラス名）、名前、値もしくはオブジェクトのＩＤが含まれる。
【００６３】
本発明は、例外発生時のスタック２０に格納されていたメソッドおよびそのメソッドの引数などのオブジェクトを表示する。実施例４などでダンプファイル４４のデータ量を削減しており、モニターに表示されるデータ量も少なくなる。例外発生時のメソッドおよび関連するオブジェクトを表示することができ、例外の解析もしやすくなる。
【実施例８】
【００６４】
例外発生時には複数のメソッドがスタック２０に格納されており、複数のメソッドがモニターに表示される。そこで、例外解析を手助けするために、所望のメソッドとそれに関連するデータがモニターに表示されるのが好ましい。そこで本発明は、図５に示すように、スタックビューア４８以外に、ソースビューア５０、オブジェクトビューア５２、およびローカル変数ビューア５４を備える。これらは、スタックビューア４８に表示されたメソッド名がコンピュータシステム１２のポインタで選択された場合に動作するものである。図６に示すように、１つのウィンドウ５６を複数に分割して、それぞれのデータが表示されるようにする。図６では、オブジェクトビューアとローカル変数ビューアとはキーボードのキー操作によって切り替わるようになっている。ローカル変数ビューアを独立して表示させるようにしても良い。属性ビューアは、マウスなどのポインタで選択されているメソッドのオブジェクトＩＤなどを示すものである。
【００６５】
ソースビューア５０は、選択されたメソッド名に対応するメソッドのデータをスタックビューア４８から受け取り、受け取ったメソッドのデータに対応するアプリケーション１０４、フレームワーク１１４、機能セット１０８を取得し、表示する。表示されるアプリケーション１０４は、Ｊａｖａソース５８かバイトコード６０の形式である。アプリケーション１０４はバイトコード６０の形式で市場に提供されるが、開発時はＪａｖａソース５８の形式であるため、プログラム１０が２つの形式に対応するようにする。
【００６６】
オブジェクトビューア５２は、選択されたメソッド名に対応するthisオブジェクトのデータをスタックビューア４８から受け取り、受け取ったthisオブジェクトのデータに対応するオブジェクトのデータをダンプファイル４４から取得し、表示する。
【００６７】
ローカル変数ビューア５４は、選択されたメソッド名に対応するthisオブジェクトのデータおよびメソッドのシグネチャをスタックビューア４８から受け取り、受け取ったthisオブジェクトのデータおよびメソッドのシグネチャに対応するメソッドからローカル変数のデータを取得し、表示する。
【００６８】
上述のように、所望のメソッドをマウスなどのポインタで選択することによって、それに関連したデータを表示することができる。例外解析の時間短縮と間違いの防止などの効果がある。
【実施例９】
【００６９】
上述したように、アプリケーション１０４はJavaソース５８またはバイトコード６０である。ソースビューア５０は、thisオブジェクトのデータに対応するJavaソース５８を取得し、Javaソース５８がなければthisオブジェクトのデータとメソッドのシグネチャに対応するバイトコード６０を取得するようにする。
【００７０】
実行ラインのデータに基づいて取得したJavaソース５８またはバイトコード６０の該当実行ラインを他の実行ラインとは区別するようにモニターで表示する。その区別は、該当実行ラインに色を付けたりマークをしたりすることが含まれる。ポインタでメソッド名が選択されると、アプリケーション１０４のどの部分が例外に関わる箇所であるかがわかるようになる。
【００７１】
モニターにダンプファイル４４を表示させるときのプログラムの動作について説明する。（１）ダンプファイル４４にあるメソッドのデータから、メソッド名、引数、ローカル変数をスタックビューア４８により表示する。
【００７２】
（２）表示した引数、ローカル変数がオブジェクトである場合、該当オブジェクトＩＤを使って、ダンプファイル４４からオブジェクトのデータを取得し、スタックビューア４８により表示する。ここまでで、メソッドおよびそれに関連するオブジェクトが表示され、例外解析をおこなう最低限のデータが表示されたこととなる。表示されたメソッド名がポインタなどで選択された場合、以下の動作をおこなう。
【００７３】
（３）スタックビューア４８は、選択されたメソッドのthisオブジェクトのID、メソッドのシグネチャおよび実行ラインのデータをソースビューア５０に送る。また、スタックビューア４８は、thisオブジェクトのIDをオブジェクトビューア５２に送る。さらに、スタックビューア４８は、thisオブジェクトのID、メソッドのシグネチャをローカル変数ビューア５４に送る。
【００７４】
（４）ソースビューア５０は、クラス名に基づいて、Javaソース５８を取得して表示する。Javaソース５８がない場合、クラス名とメソッドのシグネチャに基づいてバイトコード６０を取得して表示する。また、実行ラインの情報に基づいて、該当ラインを色分けする。
【００７５】
（５）オブジェクトビューア５２は、thisオブジェクトのIDを使用して、ダンプファイル４４から該当オブジェクトの情報を取得して表示する。該当オブジェクトのインスタンスがあれば、それもダンプファイル４４から取得して表示する。該当オブジェクトのフィールドがオブジェクトであれば、それもダンプファイル４４から取得して表示する。
【００７６】
（６）ローカル変数ビューア５４は、該当メソッドのバイトコード６０からローカル変数の情報（ID、名前、タイプ）を取得して表示する。
【００７７】
以上のように、ダンプファイル４４を項目ごとに表示することができ、例外の解析をおこない易くなっている。実施例６までの構成でダンプファイル４４のデータ量を低減していれば、更に例外の解析がし易くなる。
【００７８】
ＧＵＩを使用する場合、ダンプファイル４４はモニターのウィンドウに表示される。スタックビューア４８、ソースビューア５０、オブジェクトビューア５２、およびローカル変数ビューア５４は、図６のように１つのウィンドウ５６で表示をおこなっても良いし、それぞれ別個のウィンドウで表示をおこなっても良い。
【００７９】
以上、本発明について種々の実施例を示して説明したが、上記実施例に限定されるものではない。上記の実施例を周知の技術と組み合わせても良い。例えば、実施例１から３では例外の監視機能を説明したが、その後、実施例４以降の構成を使用せず、スタック２０に格納されたメソッドおよびそれに関連するヒープ４０のオブジェクトを全てダンプするようにしても良い。また、実施例４から６についても同様で、例外が発生すると実施例１から３をおこなわずに、実施例４から始まる構成であっても良い。さらに、実施例７から９のみの構成であってもよく、従来のコンピュータシステム１００で作成されたダンプファイルについて、実施例７から９の構成を適用するようにする。
【００８０】
本発明はJavaに関するプログラムとして説明したが、同様の構成・動作の他のプログラミング言語に本発明は適用可能である。
【００８１】
その他、本発明は、その主旨を逸脱しない範囲で当業者の知識に基づき種々の改良、修正、変更を加えた態様で実施できるものである。
【図面の簡単な説明】
【００８２】
【図１】本発明のプログラムの構成を示す図である。
【図２】本発明のプログラムの例外監視機能を示す図である。
【図３】監視する経路を示す図である。
【図４】本発明のプログラムのダンプ機能を示す図である。
【図５】本発明のプログラムのダンプファイルの表示機能を示す図である。
【図６】複数のビューアが１つのウィンドウで表示される様子を示す図である。
【図７】従来のアプリケーションの開発環境を示す図である。
【図８】従来のデータの流れを示す図である。
【符号の説明】
【００８３】
１０：プログラム
１２、１００：コンピュータシステム
１４：例外監視機能
１６：ダンプ機能
１８：表示機能
２０：スタック
２２：埋め込む手段
２４：コンフィグファイル
２６：例外監視手段
２８：ダンプ手段
３０：データを取得する手段
３２：オブジェクト・プール
３４：テンプレート
３６：チェックする手段
３８：テンプレートを取得する手段
４０：ヒープ
４２：オブジェクトを取得する手段
４４：ダンプファイル
４６：ダンプファイルの生成手段
４８：スタックビューア
５０：ソースビューア
５２：オブジェクトビューア
５４：ローカル変数ビューア
５６：ウィンドウ
５８：Ｊａｖａソース
６０：バイトコード
１０２：オペレーティングシステム
１０４：アプリケーション
１０６：Ｊａｖａ  ＶＭ
１０８機能セット
１１０：Ｊ２ＳＥ
１１２：Ｊ２ＥＥ
１１４：フレームワーク
１１６：汎用フレームワーク
１１８：専用フレームワーク
１２０：データ 
【図１】
2008186378.tif 000003
【図２】
2008186378.tif 000004
【図３】
2008186378.tif 000005
【図４】
2008186378.tif 000006
【図５】
2008186378.tif 000007
【図６】
2008186378.tif 000008
【図７】
2008186378.tif 000009
【図８】
2008186378.tif 000010