JP6247237B2 - オートリソースロギングシステム、オートリソースロギング方法及びプログラム - Google Patents

Description

本発明は、ソフトウェアの性能評価を行うために、評価対象のソフトウェア自体に、性能評価に必要なログを出力するためのロギングコードを埋め込むことが可能なオートリソースロギングシステム、オートリソースロギング方法及びプログラムに関する。

現状では、ソフトウェアの後述する性能評価を行うために必要な上述したロギングコードの埋め込みを行う場合、性能計測のためのプログラムに基づくロギングコード（文字列）を人が設計し、この設計されたロギングコードをソフトウェアに埋め込む等の手法が取られている。性能評価とは、メモリの空き容量をチェックしたり、プログラムがＣＰＵ(Central Processing Unit)リソース（使用可能量）を使用する際のプログラムカウンタをチェックしたりすることである。

また、性能評価のために、プログラムカウンタにより、ＣＰＵクロック消費量を求めたり、メモリの解放容量を検出して、メモリの空き容量を求めたりする手法も取られている。この内容を含む従来技術として特許文献１に記載のものがある。

特開２０１０−１１７７５７号公報

ところで、ソフトウェアにロギングコードを埋め込む場合、埋め込み個所が多くなるケースが多々ある。この多くの埋め込み個所にロギングコードが存在するため、ソフトウェアの性能評価のための計測区間が管理し難くなるという問題がある。

また、ロギングコードを人が設計してソフトウェアに埋め込む必要があるので、ロギングコードの埋め込みに手間が掛かるという問題がある。

更に、プロファイラによるソフトウェアの性能計測では、関数単位の時間計測しか行えない。自動で全ての関数について計測してしまうため、性能計測のための処理が増加してしまう。言い換えれば、性能を計測するためのプログラムによる計測オーバーヘッドが増加するという問題がある。

本発明は、このような背景に鑑みてなされたものであり、ソフトウェアの性能評価のための計測区間を容易に管理することができ、ソフトウェアへのロギングコードの埋め込みを容易に行うことができ、計測オーバーヘッドを減少させることができるオートリソースロギングシステム、オートリソースロギング方法及びプログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、端末機と、前記端末機からソースコードを受信してロギングコードを埋め込むプリプロセッシングを行うビルドサーバとを備えたオートリソースロギングシステムであって、前記ビルドサーバは、前記端末機で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードの計測区間を記憶する計測区間記憶部と、前記ソースコード内で性能計測を行うためのロギングコードが記憶されたロギングコード記憶部と、前記計測区間記憶部に記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードを、前記ロギングコード記憶部から取得し、この取得したロギングコードを、前記端末機から受信したソースコードに埋め込むプリプロセッシング処理を実行するプリプロセッシング機能部と、を備えることを特徴とするオートリソースロギングシステムである。

この構成によれば、ソースコードに対応するソフトウェアの性能評価のための計測区間を容易に管理することができる。また、ソフトウェアへのロギングコードの埋め込みを容易に行うことができる。更に、端末機のユーザが指定する任意の区間のみの計測が可能となるので、計測オーバーヘッドを最小化できる。言い換えれば、計測オーバーヘッドを減少させることができる。

請求項２に係る発明は、請求項１において、前記ロギングコードは、前記ソフトウェアの前記計測区間のクロック数を計測するコードを有することを特徴とする請求項１に記載のオートリソースロギングシステムである。

この構成によれば、端末機のＣＰＵクロック消費量を検出することができるので、プログラム（ソフトウェア）がどれだけＣＰＵリソースを消費したかを把握することができる。

請求項３に係る発明は、請求項１又は２において、前記ビルドサーバは、前記端末機から指定された前記計測区間のログを出力する条件としての出力閾値を記憶する閾値記憶部を更に備え、前記プリプロセッシング機能部は、前記計測区間を取得した際に、前記閾値記憶部に記憶された出力閾値も取得し、この取得した計測区間で尚且つ出力閾値以上のサイズのログを出力するためのロギングコードを、前記ソースコードに埋め込む処理を実行することを特徴とする請求項１又は２に記載のオートリソースロギングシステムである。

この構成によれば、ソフトウェアの区間計測時のログのサイズが、出力閾値で制限されるので、例えば、出力閾値を３ＭＢ（メガバイト）に設定すると、３ＭＢ未満のサイズのログは出力されず、３ＭＢ以上のログが出力されるようになる。このため、出力閾値を大きく（例えば８ＭＢ）しておけば、ノイズのような小容量のログは出力されない。また、出力閾値を「異常な値」と設定しておけば、出力閾値以上のサイズのログが出力された際に、異常と判定することが可能となる。

請求項４に係る発明は、請求項１において、前記プリプロセッシング機能部は、前記計測区間記憶部に記憶された前記計測区間の指定がメソッド単位である場合、計測区間の呼び出し元プログラムの命令を受けて、計測対象の計測区間を有する複数の下位モジュールに対して、間接的に区間計測を可能とするプログラムを更に備えることを特徴とする請求項１に記載のオートリソースロギングシステムである。

この構成によれば、計測区間の呼び出し元プログラムが１回の命令を行えば、間接的に区間計測を可能とするプログラムにより、複数の下位モジュールに対して区間計測を行うことができる。

請求項５に係る発明は、請求項１〜４の何れか１項において、前記プリプロセッシング機能部は、前記ロギングコードによる区間計測のために必要な命令による区間計測実行時のオーバーヘッドを事前に計測し、この計測オーバーヘッドを用いて、前記端末機による実行ファイルの実行時に得られる計測結果を補正可能とするロギングコードを、前記ソースコードに埋め込むことを特徴とする請求項１〜４の何れか１項に記載のオートリソースロギングシステムである。

この構成によれば、次のような作用効果が得られる。性能評価対象のソフトウエアにおいて、性能評価のために取得した計測区間の実際のクロック数に対して、区間計測時のクロック数は計測コードの実行にかかるクロック数分ずれており、このずれが計測オーバーヘッドである。例えば、実行ファイル実行時に得られる計測結果から計測オーバーヘッドを減算することにより、その計測結果を補正することができる。

請求項６に係る発明は、前記ビルドサーバは、前記ロギングコードを埋め込んだソースコードをコンパイルして、コンピュータが処理可能な実行ファイルに変換するコンパイル機能部を更に備え、前記端末機は、前記実行ファイルを実行することを特徴とする請求項１に記載のオートリソースロギングシステムである。

この構成によれば、端末機が、ソフトウェアの計測区間において、クロック数計測によるＣＰＵクロック消費量を検出することができるので、プログラム（ソフトウェア）がどれだけＣＰＵリソースを消費したかを把握することができる。また、同計測区間において、出力閾値以上のログのサイズを検出できるので、メモリの異常な解放を検出することができる。これにより、データ異常やプロセス異常を発見することができるので、ソフトウェアのバグ検出を行うことができる。

請求項７に係る発明は、端末機と、前記端末機からソースコードを受信してロギングコードを埋め込むプリプロセッシングを行うビルドサーバとを備えたオートリソースロギングシステムのオートリソースロギング方法であって、前記ビルドサーバは、前記端末機で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードの計測区間を記憶する第１ステップと、前記ソースコード内で性能計測を行うためのロギングコードを記憶する第２ステップと、前記第１ステップで記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードを、前記第２ステップで記憶されたロギングコードから取得し、この取得したロギングコードを、前記端末機から受信したソースコードに埋め込むプリプロセッシング処理を実行する第３ステップを実行することを特徴とするオートリソースロギング方法。

この方法によれば、ソースコードに対応するソフトウェアの性能評価のための計測区間を容易に管理することができる。また、ソフトウェアへのロギングコードの埋め込みを容易に行うことができる。更に、端末機のユーザが指定する任意の区間のみの計測が可能となるので、計測オーバーヘッドを減少させることができる。

請求項８に係る発明は、請求項７に記載のオートリソースロギング方法を、前記ビルドサーバとしてのコンピュータに実行させるためのプログラムである。

このプログラムによれば、ソースコードに対応するソフトウェアの性能評価のための計測区間を容易に管理することができる。また、ソフトウェアへのロギングコードの埋め込みを容易に行うことができる。更に、端末機のユーザが指定する任意の区間のみの計測が可能となるので、計測オーバーヘッドを減少させることができる。

本発明によれば、ソフトウェアの性能評価のための計測区間を容易に管理することができ、ソフトウェアへのロギングコードの埋め込みを容易に行うことができ、計測オーバーヘッドを減少させることができるオートリソースロギングシステム、オートリソースロギング方法及びプログラムを提供することができる。

本発明の実施形態に係るオートリソースロギングシステムの構成を示すブロック図である。 端末機、ビルドサーバ及び管理サーバによる通信を行うためのアカウント情報の登録や認証等の処理を説明するためのシーケンス図である。 本実施形態に係るオートリソースロギングシステムの動作説明を行うためのブロック図である。 メモリ解放ＣＳＶの一例を示す図である。 計測区間情報の具体的な一例を示す図である。 ロギングコード記憶部に記憶されるロギングコードの一例を示す第１の図である。 ロギングコード記憶部に記憶されるロギングコードの一例を示す第２の図である。図である。 プリプロセッシング機能部がロギングコードをソースコードに埋め込む際のロギング埋込の具体例を説明するための図である。 ＣＰＵクロック消費量の直接計測時に、ソースコードに埋め込まれるロギングコードの一例を示す第１の図である。 ＣＰＵクロック消費量の直接計測時に、ソースコードに埋め込まれるロギングコードの一例を示す第２の図である。 ＣＰＵクロック消費量の直接計測時において、プリプロセッシング機能部がロギングコードをソースコードに埋め込む際のロギング埋込の具体例を説明するための図である。 オーバーヘッドベンチマーク機能コードによるシングルトンの仕組みを説明するためのブロック図である。 計測オーバーヘッドの一例を示す第１の図である。 計測オーバーヘッドの一例を示す第２の図である。 消費クロックの一例を示す図である。 オートリソースロギング処理によって、端末機におけるメモリの異常な解放の検出を行う際の動作を説明するためのフローチャートである。 オートリソースロギング処理によって、端末機におけるＣＰＵクロック消費量の直接計測による検出を行う際の動作を説明するためのフローチャートである。 プリプロセッシング機能部がＣＰＵクロック消費量を間接計測で検出する際の構成を示す図である。 ＣＰＵクロック消費量の間接計測時において、プリプロセッシング機能部がロギングコードをソースコードに埋め込む際のロギング埋込の具体例を説明するための図である。

以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係るオートリソースロギングシステムの構成を示すブロック図である。
図１に示すオートリソースロギングシステム１０（単に、システム１０ともいう）は、ユーザ端末機２０と、ビルドサーバ３０と、アカウント管理サーバ４０とを備え、ソフトウェアにロギングコードを埋め込むロギング埋込を行うプリプロセッシング処理（前処理）を行うものである。ロギング埋込の処理は、端末機２０に当該ソフトウェアを実行させる前に行われる。この処理を、オートリソースロギング処理という。ロギング埋込の処理内容については、後述する。

ユーザ端末機２０、ビルドサーバ３０及びアカウント管理サーバ４０は、有線や無線回線によるインターネット回線で接続されている。なお、アカウント管理サーバ４０を管理サーバ４０ともいい、ユーザ端末機２０を端末機２０ともいう。

端末機２０は、システム１０のユーザが、アカウント情報の登録、更新、削除や認証（又は特定）要求等の各種操作を行う通信機能付のコンピュータである。この端末機２０は、通信に係る処理を行う送受信部２０ａ及びアカウント要求応答部２０ｂと、本発明の特徴構成要素の実行ファイル実行処理部２０ｃと、ソースコード記憶部２０ｄ、オーバーヘッド記憶部２０ｅ及びＣＳＶ記憶部２０ｆを有する外部記憶部２０ｇとを備える。なお、アカウント情報は、ユーザが、インターネット上のサーバやコンピュータへのログインを行う権利を得るための情報であり、ユーザのユーザＩＤ(Identification)やパスワードを含むものである。

ビルドサーバ３０は、端末機２０からソースコードＳＣを受信し、性能評価対象のソフトウェア（プログラム）にロギングコードＬＣを埋め込むプリプロセッシングを行うサーバである。このビルドサーバ３０は、通信に係る処理を行う送受信部３０ａ及びアカウント要求応答部３０ｂと、本発明の特徴であるオートリソースロギング処理に係るプリプロセッシング機能部３０ｃと、計測区間記憶部３０ｄと、閾値記憶部３０ｅと、ロギングコード記憶部３０ｆと、コンパイル機能部３０ｈとを備える。

管理サーバ４０は、ユーザのアカウント情報の登録、更新、削除や認証等を行ってアカウントの管理を行うサーバであり、送受信部４０ａ及びアカウント管理処理部４０ｂを備える。

ここで、端末機２０、ビルドサーバ３０及び管理サーバ４０における通信を行うための処理であるアカウント情報の登録、更新、削除や認証等の各種処理について説明する。

端末機２０において、送受信部２０ａは、ユーザのアカウント登録や認証に係るアカウント情報並びに、その他、後述のようにビルドサーバ３０との間で遣り取りされる各種情報を送受信する。
アカウント要求応答部２０ｂは、ユーザのアカウント情報をビルドサーバ３０を介して管理サーバ４０へ登録、更新、削除や認証する要求の制御を行うと共に、管理サーバ４０からビルドサーバ３０を介して返信されてきたアカウント登録、更新、削除や認証の応答結果を表示する制御を行う。

ビルドサーバ３０において、送受信部３０ａは、端末機２０又は管理サーバ４０との間で遣り取りされる各種情報を送受信する。
アカウント要求応答部３０ｂは、端末機２０から送信されてきた登録要求情報に応じて、管理サーバ４０にアカウント登録要求を行い、この登録要求に応じて管理サーバ４０から返信されてきた登録応答情報を、端末機２０へ送信する。また、アカウント要求応答部３０ｂは、端末機２０から送信されてきた認証要求情報に応じて、管理サーバ４０にアカウント認証要求を行い、この認証要求に応じて管理サーバ４０から返信されてきた認証応答情報を、端末機２０へ送信する。

管理サーバ４０において、送受信部４０ａは、ビルドサーバ３０との間で、上述したような各種情報を送受信する。
アカウント管理処理部４０ｂは、アカウント情報に含まれるユーザＩＤやパスワードを事前登録する処理、ユーザＩＤに紐づきユーザ情報を更新する処理、ユーザＩＤに紐づきユーザ情報を削除する処理、ユーザＩＤ及びパスワードを用いてユーザの特定を行うアカウント認証の処理を行う。

端末機２０、ビルドサーバ３０及び管理サーバ４０による通信を行うためのアカウント情報の登録や認証等の処理について、図２に示すシーケンス図を参照して詳細に説明する。

図２において、端末機２０のアカウント要求応答部２０ｂ（図１）は、ステップＳ１，Ｓ２に示すように、ユーザのアカウント情報をビルドサーバ３０を介して管理サーバ４０へ登録する要求制御（アカウント登録要求）を行う。これに応じて、ステップＳ３に示すように、管理サーバ４０がそのユーザのアカウント情報を登録する。管理サーバ４０は、そのアカウント登録の結果を、ステップＳ４，Ｓ５に示すようにビルドサーバ３０を介して端末機２０へ応答（アカウント登録応答）する。端末機２０のアカウント要求応答部２０ｂは、ステップＳ６に示すように、その返信されてきたアカウント登録結果を表示する。

また、端末機２０のアカウント要求応答部２０ｂは、ステップＳ７，Ｓ８に示すように、ユーザのアカウント情報を認証する要求制御（アカウント認証要求）をビルドサーバ３０を介して管理サーバ４０へ行う。これに応じて、ステップＳ９に示すように、管理サーバ４０がそのユーザのアカウント情報の認証を行う。管理サーバ４０は、そのアカウント認証の結果を、ステップＳ１０，Ｓ１１に示すようにビルドサーバ３０を介して端末機２０へ応答（アカウント認証応答）する。端末機２０のアカウント要求応答部２０ｂは、ステップＳ１２に示すように、その返信されてきたアカウント認証結果を、端末機２０の図示せぬ画面に表示する。認証結果がＯＫであれば後述する次の処理へ進む。

図１に戻って、端末機２０の本発明の特徴構成要素について説明する。
ソースコード記憶部２０ｄは、コンピュータでの処理が不可能なプログラミング言語で記述されたソースコードＳＣを記憶するものである。このソースコードＳＣには、後述するビルドサーバ３０においてロギングコードＬＣが埋め込まれる。ロギングコードＬＣは、ソフトウェアの性能計測のためのプログラムに基づくコードであって、ソフトウェアの性能評価に必要なログを出力するためのコードである。

実行ファイル実行処理部２０ｃは、ロギングコードＬＣが埋め込まれた実行ファイルＥＦを実行し、この結果得られるログである図３に示す後述のメモリ解放ＣＳＶ（Comma-Separated Value）並びに消費クロックＣＳＶを、外部記憶部２０ｇのＣＳＶ記憶部２０ｆに記憶するものである。外部記憶部２０ｇは、図示せぬ外部装置とのアクセスが可能な記憶部である。なお、消費クロックとは、ロギングコードＬＣ自体で性能計測のために消費してしまう、ＣＰＵに割り当てられたＣＰＵクロックである。

メモリ解放ＣＳＶは、メモリの解放情報（解放サイズの情報）をＣＳＶで表したものであり、実行ファイル実行処理部２０ｃに保持された実行ファイルＥＦの実行により、作動中のコンピュータとしての端末機２０のＣＳＶ記憶部２０ｆにメモリ解放ＣＳＶとして記憶されるものである。ＣＳＶは、必要なデータをデータ形式やファイル形式で表すフォーマットである。消費クロックＣＳＶについては後述する。

メモリ解放ＣＳＶの一例を図４に示す。図４には、メモリ解放ＣＳＶの項目として、メモリアドレス、メモリサイズ、タイムスタンプ、ファイル名、クラス名、行番号があり、これら項目において、凡例及びデータ量を示した。なお、凡例及びデータ量の補足の説明内容も示した。

図１に示すオーバーヘッド記憶部２０ｅは、後述する計測オーバーヘッドＯＨ（図３参照）を記憶するものである。

次に、ビルドサーバ３０の本発明の特徴構成要素について説明する。
計測区間記憶部３０ｄは、端末機２０で指定されたソフトウェアの、計測区間情報（図３参照）を記憶するものである。なお、計測区間記憶部３０ｄは、複数の計測区間情報を記憶できるようになっている。計測区間情報は、ソフトウェアの計測区間が、設定し易く管理が容易なテキスト形式等で表されている。

計測区間情報の一例は、次の括弧内の通りである。括弧内は、（ファイル名,計測区間の先頭の行番号,計測区間の末尾の行番号）となっている。
（ｍａｉｎＭｏｄｕｌｅ．ｃｐｐ，１３５，２０７），
（ｍａｉｎＭｏｄｕｌｅ．ｃｐｐ，２０５，２０５），
（ｓｕｂＭｏｄｕｌｅ．ｃｐｐ，１０９２，１１００），
．．．．

計測区間情報の具体的な一例を図５に示す。図５には、計測区間情報の項目として、ファイル名、計測区間先頭行番号、計測区間末尾行番号があり、これら項目において、凡例及びデータ量を示した。なお、凡例及びデータ量の補足の説明内容も示した。

閾値記憶部３０ｅは、ソフトウェアの性能評価のために出力されるログのサイズを制限する出力閾値（図３参照）を記憶するものである。例えば、出力閾値を３ＭＢに設定すると、３ＭＢ未満のサイズのログは出力されず、３ＭＢ以上のログが出力されるようになる。例えば、メモリの解放サイズの小容量のものは、殆どがノイズであり、ログ出力させる必要はない。このため、出力閾値を大きく（例えば８ＭＢ）しておけば、ノイズのような小容量のメモリ解放情報はログ出力されないようになる。また、出力閾値を「異常な値」と設定しておけば、出力閾値以上のサイズのログが出力された際に、異常と判定することが可能となる。但し、これと逆に、出力閾値は、当該出力閾値を３ＭＢに設定した場合に、３ＭＢ以下のサイズのログが出力され、３ＭＢ超のサイズのログは出力されないように定義してもよい。

出力閾値の一例は、次の括弧内の通りである。括弧内は、（ファイル名,出力値の下限,出力値の上限）となっている。但し、出力値の下限及び上限の指定なしは、空白となっている。
（ｍａｉｎＭｏｄｕｌｅ．ｃｐｐ，１３５００００， ），
（ｍａｉｎＭｏｄｕｌｅ．ｃｐｐ， ，２０５００００），
（ｓｕｂＭｏｄｕｌｅ．ｃｐｐ，１０９２００００，１１００００００），
．．．．

ロギングコード記憶部３０ｆは、図３に示す少なくとも１つ以上のロギングコードＬＣと、オーバーヘッドベンチマーク機能コード（ベンチマーク機能コードともいう）ＯＢＣとを記憶するものである。

そのロギングコードＬＣの一例を図６及び図７に示す。図６にはロギングコード（_ReleaseObject.h）ＬＣ１を、図７にはロギングコード（_ReleaseObject.cpp）ＬＣ２を示した。

図１に戻り、プリプロセッシング機能部３０ｃは、メモリの大きな解放サイズを検出するために、ソフトウェアにロギングコードＬＣを埋め込むロギング埋込を行うプリプロセッシング処理を、端末機２０に当該ソフトウェアを実行させる前に行うものである。

即ち、プリプロセッシング機能部３０ｃは、図３に示すように、計測区間記憶部３０ｄに記憶された計測区間の情報（計測区間情報）と、閾値記憶部３０ｅに記憶された出力閾値とを取得する。更に、プリプロセッシング機能部３０ｃは、その取得した計測区間で尚且つ出力閾値以上のサイズのログを出力するためのロギングコードＬＣを、ロギングコード記憶部３０ｆから取得する。更に、プリプロセッシング機能部３０ｃは、その取得したロギングコードＬＣを、端末機２０のソースコード記憶部２０ｄから受信したソースコードＳＣに埋め込むロギング埋込を行うプリプロセッシング処理を実行する。

このロギング埋込の具体例を、図８を参照して説明する。図８に示すソースコードＳＣにおいて、矢印Ｙ１で指し示す先頭の「Class::~Class(){」と、矢印Ｙ２で指し示す末尾の「}」とはデストラクタである。デストラクタは、クラス名の先頭にチルダ「~」を付けた名前のメンバ関数であり、引数も戻り値も持たないものである。

また、破線枠内の文字列はロギングコードＬＣであり、矢印Ｙ３，Ｙ４で指し示す「，」と「，」の間の文字列「abi::__cxa_demangle((typeid(*this)).name()」は関数である。この関数は、ソフトウェアの性能計測等を行うためのものである。

ロギング埋込を行う場合、ステップ（１）において、ソースコードＳＣに、矢印Ｙ１，Ｙ２で指し示すデストラクタが記述されているか否かを、ソースコードＳＣの全てにおいて探索する。この探索は、チルダ「~」を検索することにより行う。

ステップ（２）において、ソースコードＳＣ内にデストラクタが記述されていた場合、先頭と末尾のデストラクタ間に、ロギングコードＬＣを埋め込む。
ステップ（３）において、対象のロギングコードＬＣの行頭に、「１回のみの読込命令」（例えば、#pragma once）が記述されていない場合、その#pragma onceを行頭に埋め込む。

ステップ（４）において、対象のロギングコードＬＣの中に、「ヘッダファイル」（例えば、cxxabi.h）がインクルードされていない場合、#include <cxxabi.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（３）の#pragma onceが行頭に存在する場合、その#pragma onceの次行に、#include <cxxabi.h>を埋め込む。

ステップ（５）において、対象のロギングコードＬＣの中に、上記ステップ（４）と異なる「ヘッダファイル」（例えば、sys/time.h）がインクルードされていない場合、#include <sys/time.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（３）の#pragma once又は（４）のcxxabi.hが行頭に存在する場合、その#pragma once又はcxxabi.hの次行に、#include <sys/time.h>を埋め込む。

コンパイル機能部３０ｈは、そのロギングコードＬＣが埋め込まれたソースコードＳＣをコンパイルして、コンピュータがプログラムとして解釈実行できる実行ファイルＥＦを生成し、この実行ファイルＥＦを端末機２０へ出力する。

実行ファイル実行処理部２０ｃは、ロギングコードＬＣが埋め込まれた実行ファイルＥＦを実行処理する。この実行により、端末機２０のソフトウェア上の指定された計測区間において、メモリの出力閾値（例えば３ＭＢ）以上のログが検出された場合、このログがメモリ解放ＣＳＶとして外部記憶部２０ｇへ出力される。言い換えれば、メモリの異常な解放が検出される。

このようにメモリの異常な解放を検出することにより、データ異常やプロセス異常を発見することができるので、ソフトウェアのバグ検出が可能となる。なお、プロセス異常とは、ＯＳ(Operating System)からメモリ領域等の割り当てを受けて処理を実行しているプログラムとしてのプロセスの異常をいう。マルチプロセスシステム（既存の電話系システム等）のプロセスは、プロセス毎にメモリ利用量に変動は無い傾向がある。しかし、これをシングルプロセスで実現した場合は、１プロセスで動作することもあり、データ数に応じて必要なメモリ容量がダイナミックに変動し、プロセス異常となるケースがある。

次に、プリプロセッシング機能部３０ｃは、後述するＣＰＵクロック消費量の直接計測による検出を行うために、計測区間記憶部３０ｄから計測区間を取得し、ソースコードＳＣにおける、その取得した計測区間の前後の行に、ロギングコード記憶部３０ｆから取得したロギングコードＬＣのアセンブリコード（後述）を埋め込みする。一般的にロギングコードＬＣには、Ｃ++コードと、アセンブリコードとがあるので、本実施形態では、アセンブリコードを用いるようになっている。

この際のロギングコードＬＣの一例を図９及び図１０に示す。図９にはロギングコード（_ClockAssign.h）ＬＣ３を、図１０にはロギングコード（_ClockAssign.cpp）ＬＣ４を示した。

このロギング埋込の具体例を、図１１を参照して説明する。図１１に示すソースコードＳＣにおいて、矢印Ｙ５で指し示す先頭の「Class::func(){」と、矢印Ｙ６で指し示す末尾の「}」とはデストラクタである。

また、破線枠内の文字列はロギングコードＬＣであり、破線枠ＡＣ０，ＡＣ１で囲んだ文字列は、ロギングコードＬＣのアセンブリコードである。

ロギング埋込を行う場合、ステップ（１１）において、計測区間記憶部３０ｄに記憶された計測区間情報の、矢印Ｙ７で指し示す計測対象の区間の前後に、破線枠ＡＣ０，ＡＣ１で囲むロギングコードＬＣのアセンブリコードを埋め込む。

ステップ（１２）において、対象のロギングコードＬＣの行頭に、「１回のみの読込命令」（例えば、#pragma once）が記述されていない場合、その#pragma onceを行頭に埋め込む。

ステップ（１３）において、対象のロギングコードＬＣの中に、「ヘッダファイル」（例えば、cxxabi.h）がインクルードされていない場合、#include <cxxabi.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（１２）の#pragma onceが行頭に存在する場合、その#pragma onceの次行に、#include <cxxabi.h>を埋め込む。

ステップ（１４）において、対象のロギングコードＬＣの中に、上記ステップ（１３）と異なる「ヘッダファイル」（例えば、sys/time.h）がインクルードされていない場合、#include <sys/time.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（２）の#pragma once又は（３）のcxxabi.hが行頭に存在する場合、その#pragma once又はcxxabi.hの次行に、#include <sys/time.h>を埋め込む。

プリプロセッシング機能部３０ｃは、更に、ロギングコード記憶部３０ｆからベンチマーク機能コードＯＢＣを取得し、これをロギングコードＬＣと関連付けてソースコードＳＣに埋め込む。
ベンチマーク機能コードＯＢＣは、後述する実行ファイル実行処理部２０ｃによる実行ファイルＥＦの実行時に、ロギングコードＬＣによるソフトウェアの区間計測の命令実行時のオーバーヘッドを事前に計測し、この計測されたオーバーヘッド（計測オーバーヘッドＯＨ）で、ソースコードＳＣ上の区間計測結果を補正するコードである。

ここで、計測オーバーヘッドＯＨについて説明する。性能評価対象のソフトウエアにおいて、性能評価のために取得したい計測区間（例えば０〜１５００クロック数の区間）を実測した際に、計測開始から終了まで１５１５クロック数だったすると、１５１５−１５００＝１５の差分が、計測オーバーヘッドＯＨとなる。つまり、ソースコードＳＣ上の区間計測結果から、計測オーバーヘッドＯＨを減算することにより、その区間計測結果を補正することができる。

コンパイル機能部３０ｈは、そのロギングコードＬＣが埋め込まれたソースコードＳＣをコンパイルして、コンピュータがプログラムとして解釈実行できる実行ファイルＥＦに変換し、この実行ファイルＥＦを端末機２０の実行ファイル実行処理部２０ｃへ出力する。

実行ファイル実行処理部２０ｃは、実行ファイルＥＦを実行する。この実行により、ロギングコードＬＣによるソフトウェアの区間計測が行われ、この際に、ベンチマーク機能コードＯＢＣによるシングルトンの仕組み（後述する）が用いられて、ソースコードＳＣ上の区間計測結果が補正される。

シングルトンの仕組みとは、図１２に示す計測モジュールＭＭ、ベンチマークモジュールＢＭ、及びオーバーヘッド記憶部２０ｅにより、オーバーヘッドのベンチマーク機能（後述する）を実現するものである。

計測モジュールＭＭは、ソフトウェアの区間計測を、計測区間を呼び出す上位モジュールと下位モジュール（ここではベンチマークモジュールＢＭ）との間にあって、間接的に区間計測を行うためのプログラムである。
ベンチマークモジュールＢＭとは、ロギングコードＬＣ自体で測定のために消費してしまうＣＰＵクロックを測定するためのプログラムである。

即ち、シングルトンの仕組みとは、１回目のソフトウェアの区間計測時に、計測モジュールＭＭがベンチマークモジュールＢＭ（後述）にアクセスして、その区間計測の命令実行時のオーバーヘッドを計測し、この計測オーバーヘッドＯＨをオーバーヘッド記憶部２０ｅに記憶する。この記憶後、２回目以降のソフトウェアの区間計測時には、計測の都度、１回のみ、計測モジュールＭＭがオーバーヘッド記憶部２０ｅにアクセスして計測オーバーヘッドＯＨを取得可能とする仕組みである。この仕組みの動作を行う機能がベンチマーク機能である。

なお、オーバーヘッド記憶部２０ｅに記憶される計測オーバーヘッドＯＨの一例を図１３及び図１４に示す。図１３には計測オーバーヘッドコード（_OverHead.h）ＯＨ１を、図１４には計測オーバーヘッドコード（_OverHead.cpp）ＯＨ２を示した。

このベンチマーク機能によれば、実行ファイルＥＦの実行時に、ロギングコードＬＣに応じてソフトウェアの区間計測を行った際に、その区間計測の命令実行時の計測オーバーヘッドＯＨを、その計測区間上のＣＰＵクロック数の計測結果から減算することで、計測結果が補正される。この補正後に、ＣＰＵクロック数の区間計測結果である消費クロックＣＳＶを、ＣＳＶ記憶部２０ｆに記憶する。

更に説明すると、実行ファイルＥＦの実行により、端末機２０のソフトウェア上の指定された計測区間におけるＣＰＵクロック数が検出される。この検出クロック数により、後述するＣＰＵクロック消費量が検出され、このログが、消費クロックＣＳＶとして外部記憶部２０ｇへ出力される。

ここで、ＣＰＵクロック消費量とは、例えば２．２ＧＨｚ等の定格クロックをどれだけ消費したかを示す消費量であり、ＣＰＵの中に実装された図示せぬプログラムカウンタで計数する。このプログラムカウンタでの計数は、例えばクロックが論理回路を通過して元に戻った際にプログラムカウンタを１加算する。このように、ＣＰＵクロック消費量を検出することにより、プログラム（ソフトウェア）がどれだけＣＰＵリソースを消費したかを把握することが可能となる。通常、ＯＳで標準装備されているリソースモニタでは、プログラムがどれだけＣＰＵリソースを消費したかをクロック数単位で把握することはできない。

消費クロックＣＳＶの一例を図１５に示す。図１５には、消費クロックＣＳＶの項目として、クロック数、タイムスタンプ（開始）、タイムスタンプ（終了）、ファイル名、クラス名、行番号があり、これら項目において、凡例及びデータ量を示した。なお、凡例及びデータ量の補足の説明内容も示した。

＜実施形態の動作＞
次に、本実施形態に係るオートリソースロギングシステム１０によるオートリソースロギング処理の動作を、図１６〜図１７に示すフローチャートを参照して説明する。但し、端末機２０、ビルドサーバ３０及び管理サーバ４０において、図２のステップＳ１〜Ｓ１２の処理は完了し、認証結果はＯＫであったとする。

また、事前準備として、端末機２０で指定されたソフトウェアの計測区間の情報（図３の計測区間情報）が計測区間記憶部３０ｄに記憶され、ソフトウェアの性能評価のために出力されるログのサイズを制限する出力閾値（図３参照）が閾値記憶部３０ｅに記憶され、更に、ロギングコードＬＣ及びベンチマーク機能コードＯＢＣがロギングコード記憶部３０ｆに記憶されているとする。

最初に、オートリソースロギング処理によって、端末機２０におけるメモリの異常な解放の検出を行う際の動作について、図１６を参照して説明する。

まず、図１６に示すステップＳ１０１において、端末機２０からソースコードＳＣが送信（図２のＳ１３参照）されると、ビルドサーバ３０のプリプロセッシング機能部３０ｃは、そのソースコードＳＣを受信する。

次に、ステップＳ１０２において、プリプロセッシング機能部３０ｃは、計測区間記憶部３０ｄに記憶された計測区間情報と、閾値記憶部３０ｅに記憶された出力閾値とを取得する。更に、ステップＳ１０３において、プリプロセッシング機能部３０ｃは、その取得した計測区間で且つ出力閾値以上のサイズのログを出力するためのロギングコードＬＣを、ロギングコード記憶部３０ｆから取得する。

次に、ステップＳ１０４において、プリプロセッシング機能部３０ｃは、その取得したロギングコードＬＣを、端末機２０から受信したソースコードＳＣに埋め込むロギング埋込を行う（図２のＳ１４参照）。

次に、ステップＳ１０５において、図３に示すように、コンパイル機能部３０ｈは、ロギングコードＬＣが埋め込まれたソースコードＳＣを取得してコンパイルする。このコンパイルによりロギングコードＬＣが埋め込まれた実行ファイルＥＦが生成され、端末機２０の実行ファイル実行処理部２０ｃへ出力される（図２のＳ１６参照）。

次に、ステップＳ１０６において、実行ファイル実行処理部２０ｃは、実行ファイルＥＦを実行処理する（図２のＳ１７参照）。この実行により、ステップＳ１０７において、端末機２０のソフトウェア上の指定された計測区間において、メモリの出力閾値以上の大きな解放サイズが検出されたか否かが判定される。

この結果、メモリの出力閾値以上の大きな解放サイズが検出された場合、ステップＳ１０８において、その検出結果（ログ）がメモリ解放ＣＳＶとしてＣＳＶ記憶部２０ｆへ出力される（図２のＳ１８参照）。言い換えれば、メモリの異常な解放がメモリ解放ＣＳＶとして出力される。このメモリ解放ＣＳＶとしてのメモリの異常な解放の検出情報により、データ異常やプロセス異常を発見することができ、ソフトウェアのバグ検出が可能となる。一方、検出されない場合、ログは出力されず、本処理は終了する。

次に、オートリソースロギング処理によって、端末機２０におけるＣＰＵクロック消費量の直接計測による検出を行う際の動作について、図１７を参照して説明する。但し、初期条件において、オーバーヘッド記憶部２０ｅには、計測オーバーヘッドＯＨは記憶されていないとする。

まず、図１７に示すステップＳ２０１は、図１６のステップＳ１０１と同じ処理である。
次に、ステップＳ２０２において、プリプロセッシング機能部３０ｃは、計測区間記憶部３０ｄに記憶された計測区間情報を取得する。更に、ステップＳ２０３において、プリプロセッシング機能部３０ｃは、その取得した計測区間でそのログを出力するためのロギングコードＬＣと、このロギングコードＬＣによる区間計測実行時のオーバーヘッドによる計測結果を補正するためのベンチマーク機能コードＯＢＣとを取得する。

次に、ステップＳ２０４において、プリプロセッシング機能部３０ｃは、その取得したロギングコードＬＣ及びベンチマーク機能コードＯＢＣを、端末機２０から受信したソースコードＳＣに埋め込むロギング埋込を行う。

次に、ステップＳ２０５において、図３に示すように、コンパイル機能部３０ｈは、ソースコードＳＣを取得してコンパイルする。このコンパイルによりロギングコードＬＣ及びベンチマーク機能コードＯＢＣが埋め込まれた実行ファイルＥＦが生成され、端末機２０の実行ファイル実行処理部２０ｃへ出力される。

ステップＳ２０６において、実行ファイル実行処理部２０ｃは、実行ファイルＥＦを実行処理する。この実行により、ステップＳ２０７において、ロギングコードＬＣによるソフトウェアの区間計測の命令実行時のオーバーヘッドが計測され、この計測オーバーヘッドＯＨがオーバーヘッド記憶部２０ｅに記憶される。

ステップＳ２０８において、実行ファイル実行処理部２０ｃは、上記ステップＳ２０７の計測オーバーヘッドＯＨを用い、上記ソフトウェアの区間計測の命令実行時の、計測区間上のＣＰＵクロック数の計測結果を補正する。即ち、計測区間上のＣＰＵクロック数の計測結果から計測オーバーヘッドＯＨを減算することで、計測結果を補正する。

この補正後に、ステップＳ２０９において、実行ファイル実行処理部２０ｃは、ＣＰＵクロック数の区間計測結果である消費クロックＣＳＶを、ＣＳＶ記憶部２０ｆに出力して記憶する。この記憶された消費クロックＣＳＶからＣＰＵクロック消費量を認識することができる。

但し、実行ファイルＥＦの実行時に、オーバーヘッド記憶部２０ｅに計測オーバーヘッドＯＨが記憶されていれば、この記憶された計測オーバーヘッドＯＨを用いて上記ステップＳ２０８の補正を行う。一方、計測オーバーヘッドＯＨが記憶されていなければ、上記ステップＳ２０７のオーバーヘッドの計測を行って記憶し、上記ステップＳ２０８の補正を行う。

＜ＣＰＵクロック消費量の他の検出処理例＞
次に、ＣＰＵクロック消費量を間接計測で検出する際の処理について説明する。

本例では、プリプロセッシング機能部３０ｃが、計測区間記憶部３０ｄから計測区間情報を取得する際に、その計測区間情報の取得の指定が、ある纏まりのメソッド単位である場合、計測区間情報の呼び出し元プログラムの命令を受けて、間接的に区間計測を可能とするプログラムを備え、ＣＰＵクロック消費量を間接計測により検出できるようにした。

この構成は、図１８に示すように、呼び出し元プログラムとしての上位モジュールＪＭと、区間計測対象がモジュール単位（又はメソッド単位）である場合、これに対応した複数の下位モジュールＫＭ１〜ＫＭ４と、上位モジュールＪＭと下位モジュールＫＭ１〜ＫＭ４との間に介在された計測モジュールＭＭＡとを備えて成る。なお、計測モジュールＭＭＡは、請求項記載の間接的に区間計測を可能とするプログラムである。

計測モジュールＭＭＡは、上位モジュールＪＭから矢印Ｙ２１で示す区間計測の命令を受けて、同種の下位モジュールＫＭ１，ＫＭ２の各々に、矢印Ｙ２１ａ，Ｙ２１ｂで示すように区間計測の命令を行うものである。これにより、ビルド範囲を局所化し、ビルド時間の短縮できるようになっている。計測モジュールＭＭＡは、破線枠Ｗ１で囲むように、上位モジュールＪＭと同一ファイル内に埋め込まれている。
なお、計測モジュールＭＭＡが存在しない通常の場合は、矢印Ｙ２２，Ｙ２３で示すように、上位モジュールＪＭから、下位モジュールＫＭ３、ＫＭ４毎に区間計測の命令を行う。

ここで、プリプロセッシング機能部３０ｃの上位モジュールＪＭが、図１８に示した構成を用いて、ソースコードＳＣに、ロギングコード記憶部３０ｆから取得したロギングコードＬＣを埋め込む場合の具体例を、図１９を参照して説明する。図１９に示すソースコードＳＣにおいて、矢印Ｙ８で指し示す先頭の「void __check(void *l_func()){」と、矢印Ｙ９で指し示す末尾の「}」とはメソッド__checkの末尾である。

また、破線枠内の文字列はロギングコードＬＣであり、破線枠ＡＣ０，ＡＣ１で囲んだ文字列は、ロギングコードＬＣのアセンブリコードである。

まず、ステップ（２１）において、計測区間記憶部３０ｄに記憶された計測区間情報の、矢印Ｙ１０で指し示す計測対象の区間（l_func();）の前後に、破線枠ＡＣ０，ＡＣ１で囲むロギングコードＬＣのアセンブリコードを埋め込む。

ステップ（２２）において、対象のロギングコードＬＣの行頭に、「１回のみの読込命令」（例えば、#pragma once）が記述されていない場合、その#pragma onceを行頭に埋め込む。

ステップ（２３）において、対象のロギングコードＬＣの中に、「ヘッダファイル」（例えば、cxxabi.h）がインクルードされていない場合、#include <cxxabi.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（２２）の#pragma onceが行頭に存在する場合、その#pragma onceの次行に、#include <cxxabi.h>を埋め込む。

ステップ（２４）において、対象のロギングコードＬＣの中に、上記ステップ（２３）と異なる「ヘッダファイル」（例えば、sys/time.h）がインクルードされていない場合、#include <sys/time.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（２２）の#pragma once又は（２３）のcxxabi.hが行頭に存在する場合、その#pragma once又はcxxabi.hの次行に、#include <sys/time.h>を埋め込む。

次に、計測モジュールＭＭＡが、上位モジュールＪＭから区間計測の命令を受けて、同じ種類の下位モジュールＫＭ１，ＫＭ２の各々に区間計測を可能とする際のコードの具体例を次に示し、その埋め込みを説明する。

ｉｎｔ ｍａｉｎ（）｛
・・・
ｆｕｎｃ１（）； −＞ ＿＿ｃｈｅｃｋ（ｆｕｎｃ１）；（＊１）
ｆｕｎｃ２（）； −＞ ＿＿ｃｈｅｃｋ（ｆｕｎｃ２）；（＊２）
ｆｕｎｃ３（）；
ｆｕｎｃ４（）；
・・・
｝

まず、ステップ（３１）において、計測区間記憶部３０ｄに記憶されたメソッドの呼び出し元ファイル（プログラム）のメソッドを、上記コードの符号＊１，＊２で示す行のように書き換える。

ステップ（３２）において、対象のロギングコードＬＣの行頭に、「１回のみの読込命令」（例えば、#pragma once）が記述されていない場合、その#pragma onceを行頭に埋め込む。

ステップ（３３）において、対象のロギングコードＬＣの中に、「ヘッダファイル」（例えば、cxxabi.h）がインクルードされていない場合、#include <cxxabi.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（３２）の#pragma onceが行頭に存在する場合、その#pragma onceの次行に、#include <cxxabi.h>を埋め込む。

ステップ（３４）において、対象のロギングコードＬＣの中に、上記ステップ（３３）と異なる「ヘッダファイル」（例えば、sys/time.h）がインクルードされていない場合、#include <sys/time.h>を、対象のロギングコードＬＣの中に埋め込む。但し、上記ステップ（３２）の#pragma once又は（３３）のcxxabi.hが行頭に存在する場合、その#pragma once又はcxxabi.hの次行に、#include <sys/time.h>を埋め込む。

この後、プリプロセッシング機能部３０ｃは、更に、ロギングコード記憶部３０ｆからベンチマーク機能コードＯＢＣを取得し、これをロギングコードＬＣと関連付けてソースコードＳＣに埋め込む。後の処理は、前述したＣＰＵクロック消費量の直接計測による検出時の処理と同じである。

＜実施形態の効果＞
以上説明した本実施形態のオートリソースロギングシステム１０は、端末機２０と、端末機２０からソースコードＳＣを受信してロギングコードＬＣを埋め込むプリプロセッシングを行うビルドサーバ３０とを備える。

本実施形態の特徴は、ビルドサーバ３０が、端末機２０から指定され、当該端末機２０で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードＳＣの計測区間を記憶する計測区間記憶部３０ｄと、ソースコードＳＣ内で性能計測を行うためのロギングコードＬＣが記憶されたロギングコード記憶部３０ｆと、計測区間記憶部３０ｄに記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードＬＣを、ロギングコード記憶部３０ｆから取得し、この取得したロギングコードＬＣを、端末機２０から受信したソースコードＳＣに埋め込むプリプロセッシング処理を実行するプリプロセッシング機能部３０ｃとを備える構成とした。

この構成によれば、ソースコードＳＣに対応するソフトウェアの性能評価のための計測区間を容易に管理することができる。また、ソフトウェアへのロギングコードＬＣの埋め込みを容易に行うことができる。更に、端末機２０のユーザが指定する任意の区間のみの計測が可能となるので、計測オーバーヘッドを最小化できる。言い換えれば、計測オーバーヘッドを減少させることができる。

また、ロギングコードＬＣは、ソフトウェアの計測区間のクロック数を計測するコードを有することとした。
これによって、端末機２０のＣＰＵクロック消費量を検出することができるので、プログラム（ソフトウェア）がどれだけＣＰＵリソースを消費したかを把握することができる。

また、ビルドサーバ３０は、端末機２０から指定された計測区間のログを出力する条件としての出力閾値を記憶する閾値記憶部３０ｅを更に備え、プリプロセッシング機能部３０ｃは、計測区間を取得した際に、閾値記憶部３０ｅに記憶された出力閾値も取得し、この取得した計測区間で尚且つ出力閾値以上のサイズのログを出力するためのロギングコードＬＣを、ソースコードＳＣに埋め込む処理を実行するようにした。

これによって、ソフトウェアの区間計測時のログのサイズが、出力閾値で制限されるので、例えば、出力閾値を３ＭＢに設定すると、３ＭＢ未満のサイズのログは出力されず、３ＭＢ以上のログが出力されるようになる。このため、出力閾値を大きく（例えば８ＭＢ）しておけば、ノイズのような小容量のログは出力されない。また、出力閾値以上のサイズのログが出力された際に、「異常な値」と設定しておけば、出力閾値以上のサイズのログが出力された際に、異常と判定することが可能となる。

また、プリプロセッシング機能部３０ｃは、計測区間記憶部３０ｄに記憶された計測区間の指定がメソッド単位である場合、計測区間の呼び出し元プログラムの命令を受けて、計測対象の計測区間を有する複数の下位モジュールに対して、間接的に区間計測を可能とするプログラムを更に備える構成とした。

この構成によれば、計測区間の呼び出し元プログラムが１回の命令を行えは、間接的に区間計測を可能とするプログラムにより、複数の下位モジュールに対して区間計測を行うことができる。

また、プリプロセッシング機能部３０ｃは、ロギングコードＬＣによる計測のために必要な命令による区間計測実行時のオーバーヘッドを事前に計測し、この計測オーバーヘッドを用いて、端末機２０による実行ファイルＥＦの実行時に得られる計測結果を補正可能とするロギングコードＬＣを、ソースコードＳＣ上に備える構成とした。

この構成によれば、次のような作用効果が得られる。性能評価対象のソフトウエアにおいて、性能評価のために取得した計測区間の実際のクロック数に対して、区間計測時のクロック数はずれており、このずれが計測オーバーヘッドである。例えば、実行ファイルＥＦ実行時に得られる計測結果から計測オーバーヘッドを減算することにより、その計測結果を補正することができる。

また、ビルドサーバ３０は、ロギングコードＬＣを埋め込んだソースコードＳＣをコンパイルして、コンピュータが処理可能な実行ファイルＥＦに変換するコンパイル機能部を更に備える構成とし、端末機２０は、実行ファイルＥＦを実行するようにした。

この構成によれば、端末機２０が、ソフトウェアの計測区間において、クロック数計測によるＣＰＵクロック消費量を検出することができるので、プログラム（ソフトウェア）がどれだけＣＰＵリソースを消費したかを把握することができる。また、同計測区間において、出力閾値以上のログのサイズを検出できるので、メモリの異常な解放を検出することができる。これにより、データ異常やプロセス異常を発見することができるので、ソフトウェアのバグ検出を行うことができる。

また、ビルドサーバ３０は、次の第１〜第３ステップのオートリソースロギング方法を実行してもよい。
第１ステップにおいて、端末機２０から指定され、当該端末機２０で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードＳＣの計測区間を記憶する。
第２ステップにおいて、ソースコードＳＣ内で性能計測を行うためのロギングコードＬＣを記憶する。

第３ステップにおいて、第１ステップで記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードＬＣを、第２ステップで記憶されたロギングコードＬＣから取得し、この取得したロギングコードＬＣを、端末機２０から受信したソースコードＳＣに埋め込むプリプロセッシング処理を実行する。

この方法によれば、ソースコードＳＣに対応するソフトウェアの性能評価のための計測区間を容易に管理することができる。また、ソフトウェアへのロギングコードＬＣの埋め込みを容易に行うことができる。更に、端末機２０のユーザが指定する任意の区間のみの計測が可能となるので、計測オーバーヘッドを減少させることができる。

更に、上記のオートリソースロギング方法を、ビルドサーバ３０としてのコンピュータに実行させるためのプログラムを備えてもよい。このプログラムによっても、オートリソースロギング方法と同様な効果が得られる。

その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

１０ オートリソースロギングシステム
２０ ユーザ端末機
２０ａ 送受信部
２０ｂ アカウント要求応答部
２０ｃ 実行ファイル実行処理部
２０ｄ ソースコード記憶部
２０ｅ オーバーヘッド記憶部
２０ｆ ＣＳＶ記憶部
２０ｇ 外部記憶部
３０ ビルドサーバ
３０ａ 送受信部
３０ｂ アカウント要求応答部
３０ｃ プリプロセッシング機能部
３０ｄ 計測区間記憶部
３０ｅ 閾値記憶部
３０ｆ ロギングコード記憶部
３０ｈ コンパイル機能部
４０ アカウント管理サーバ
４０ａ 送受信部
４０ｂ アカウント管理処理部

Claims (8)

1. 端末機と、前記端末機からソースコードを受信してロギングコードを埋め込むプリプロセッシングを行うビルドサーバとを備えたオートリソースロギングシステムであって、
   前記ビルドサーバは、
   前記端末機で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードの計測区間を記憶する計測区間記憶部と、
   前記ソースコード内で性能計測を行うためのロギングコードが記憶されたロギングコード記憶部と、
   前記計測区間記憶部に記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードを、前記ロギングコード記憶部から取得し、この取得したロギングコードを、前記端末機から受信したソースコードに埋め込むプリプロセッシング処理を実行するプリプロセッシング機能部と、
   を備えることを特徴とするオートリソースロギングシステム。
2. 前記ロギングコードは、前記ソフトウェアの前記計測区間のクロック数を計測するコードを有する
   ことを特徴とする請求項１に記載のオートリソースロギングシステム。
3. 前記ビルドサーバは、前記端末機から指定された前記計測区間のログを出力する条件としての出力閾値を記憶する閾値記憶部を更に備え、
   前記プリプロセッシング機能部は、前記計測区間を取得した際に、前記閾値記憶部に記憶された出力閾値も取得し、この取得した計測区間で尚且つ出力閾値以上のサイズのログを出力するためのロギングコードを、前記ソースコードに埋め込む処理を実行する
   ことを特徴とする請求項１又は２に記載のオートリソースロギングシステム。
4. 前記プリプロセッシング機能部は、前記計測区間記憶部に記憶された前記計測区間の指定がメソッド単位である場合、計測区間の呼び出し元プログラムの命令を受けて、計測対象の計測区間を有する複数の下位モジュールに対して、間接的に区間計測を可能とするプログラムを更に備えることを特徴とする請求項１に記載のオートリソースロギングシステム。
5. 前記プリプロセッシング機能部は、前記ロギングコードによる区間計測のために必要な命令による区間計測実行時のオーバーヘッドを事前に計測し、この計測オーバーヘッドを用いて、前記端末機による実行ファイルの実行時に得られる計測結果を補正可能とするロギングコードを、前記ソースコードに埋め込むことを特徴とする請求項１〜４の何れか１項に記載のオートリソースロギングシステム。
6. 前記ビルドサーバは、前記ロギングコードを埋め込んだソースコードをコンパイルして、コンピュータが処理可能な実行ファイルに変換するコンパイル機能部を更に備え、
   前記端末機は、前記実行ファイルを実行する
   ことを特徴とする請求項１に記載のオートリソースロギングシステム。
7. 端末機と、前記端末機からソースコードを受信してロギングコードを埋め込むプリプロセッシングを行うビルドサーバとを備えたオートリソースロギングシステムのオートリソースロギング方法であって、
   前記ビルドサーバは、
   前記端末機で実行されるソフトウェアの性能評価を行うための、当該ソフトウェアに対応するソースコードの計測区間を記憶する第１ステップと、
   前記ソースコード内で性能計測を行うためのロギングコードを記憶する第２ステップと、
   前記第１ステップで記憶された計測区間を取得し、この取得した計測区間での性能評価のための計測によるログを出力する命令を行うロギングコードを、前記第２ステップで記憶されたロギングコードから取得し、この取得したロギングコードを、前記端末機から受信したソースコードに埋め込むプリプロセッシング処理を実行する第３ステップ
   を実行することを特徴とするオートリソースロギング方法。
8. 請求項７に記載のオートリソースロギング方法を、前記ビルドサーバとしてのコンピュータに実行させるためのプログラム。

Images