JP6449804B2 - メモリー被疑部検出のための方法およびシステム - Google Patents

Description

関連出願への相互参照および優先権
本出願は、２０１５年１２月１６日付で出願されたインド国特許出願第４７２１／ＭＵＭ／２０１５（発明の名称：メモリー被疑部検出のための方法およびシステム）に基づく優先権を主張する。該インド国特許出願の開示内容の全てが、参照によりここに組み込まれる。

本発明は、一般に、実行時アプリケーション環境（runtime application environment）における複数のメモリー被疑部（memory suspects）の検出に関する。

アプリケーション環境において、アプリケーション応答時間（application response time）およびメモリー使用量（memory utilization）は、アプリケーションの効率に影響を与え得る重要な要素である。アプリケーション応答時間およびメモリー使用量は、使用量の観点から２つの異なるリソースと考えられることがあるが、アプリケーションの応答時間は、メモリー使用量と密接に関連している。アプリケーションに関するアプリケーションデータがメモリー内にキャッシュ（cached）されるのであれば、アプリケーションの応答時間を改善することが可能である。大規模アプリケーション環境において、メモリー内へのデータのキャッシュは、いくつかの特定の課題を提起する。例えば、多くの業務用アプリケーションは、遅い応答時間やメモリーエラーの発生のような深刻な性能問題に直面している。このような問題は、別のバージョン・環境への移行、アプリケーションおよび／またはサーバーの更新、サードパーティーコンポーネントの導入等の際に頻繁に観測されるものである。

メモリーキャッシュに関連する問題を特定するための既存の方法では、後にいくつかのメモリー解析ツールの助けを借りて解析されるヒープダンプ（heap dump:動的なメモリー割り当てに使われるメモリー領域）に対して性能評価が定期的に実行される。異なる方法において、アプリケーションは、メモリー（オブジェクト）割り当てをプロファイル、またはｎ番目の割り当ての全てをプロファイルするプロファイラー（profiler）と共に使用され、適切なメモリー使用が把握される。このアプローチは複数の重いオブジェクトを特定するが、いくつかのケースでは、根本原因または対応するユースケース（use case：システムの振る舞いを記述したもの）のみを特定する。これら既存の方法における主たる目的は、メモリーを大量使用しているオブジェクトを取得または探し出す（isolate）ことにある。しかしながら、多くのケースにおいて、メモリー管理ミス（memory mismanagement）は、オブジェクトやオブジェクトがどの位置に生成されるかに関連するだけでなく、アプリケーションのユースケースにも関連する。１つ以上のユースケース／状況において、同じコードが使用される可能性がある。したがって、基本的な技術に関わりなく、メモリーの不適切な使用は、メモリーエラーを引き起こすだけでなく、応答時間に劇的な影響を与え得る。したがって、メモリーの適切な使用をモニタリングし、追跡することは、より良いアプリケーション性能のために有用となり得る。

以下の記述は、本発明の基本的な理解を提供するために、本発明のいくつかの実施形態の簡略化された要約を提供するものである。この概要は、実施形態の詳細な概観ではない。本概要は、本発明の重要／決定的な要素を特定、または本発明の範囲を正確に記述するよう意図されたものではない。本概要の唯一つの目的は、以下に提供されるより詳細な記述の前置きとして、簡略化された形式で、いくつかの実施形態を提供することにある。

上述の事項を参照し、実施形態の１つにおいて、複数のメモリー被疑部（memory suspects）の検出のための方法およびシステムが提供される。１つの様態において、複数のメモリー被疑部の検出のためのコンピューター実施方法が提供される。本方法は、アプリケーションに関連する複数の処理（transactions）を系統的に（systematically）実行する工程を含む。複数の処理を実行する工程は、メトリクス（metrics：評価尺度、管理指標）の生成をもたらす。１つの処理の実行において生成されたメトリクスは、該１つの処理に関連するメモリー割り当て情報と、アプリケーションメモリー情報とを含む。複数の処理を系統的に処理している間に生成されたメトリクスは、定期的に取得される。定期的に取得されるメトリクスに基づいて、複数の被疑メモリー割り当て（suspected memory allocations）による影響を受ける複数の処理の中から、複数の処理のセットが検出される。メトリクスのメモリー割り当て情報は、影響を受ける複数の処理のセットの特定を容易にする。

異なる様態において、複数のメモリー被疑部の検出のためのコンピューター実施システムが提供される。本システムは、少なくとも１つのメモリーと、該メモリーに接続された少なくとも１つのプロセッサーとを含む。少なくとも１つのプロセッサーは、少なくとも１つのメモリー内に保存されている複数のプログラム命令（programmed instructions）を実行することによって、アプリケーションに関連する複数の処理を系統的に実行する工程を実行する。複数の処理を実行する工程は、メトリクスの生成をもたらす。１つの処理の実行において生成されたメトリクスは、該１つの処理に関連するメモリー割り当て情報と、アプリケーションメモリー情報とを含む。複数の処理を系統的に処理している間に生成されたメトリクスは、定期的に取得される。定期的に取得されたメトリクスに基づいて、複数の被疑メモリー割り当てによる影響を受ける複数の処理の中から、複数の処理のセットが検出される。メトリクスのメモリー割り当て情報は、影響を受ける複数の処理のセットの特定を容易にする。

さらに異なる様態において、複数のメモリー被疑部の検出のための方法を実行するためのコンピュータープログラムを有する（コンピュータープログラムが具体化された）非一時的コンピューター可読媒体（non-transitory computer-readable medium）が提供される。本方法は、アプリケーションに関連する複数の処理を系統的に実行する工程を含む。複数の処理を実行する工程は、メトリクスの生成をもたらす。１つの処理の実行において生成されたメトリクスは、該１つの処理に関連するメモリー割り当て情報と、アプリケーションメモリー情報とを含む。複数の処理を系統的に処理している間に生成されたメトリクスは、定期的に取得される。定期的に取得されたメトリクスに基づいて、複数の被疑メモリー割り当てによる影響を受ける複数の処理の中から、複数の処理のセットが検出される。メトリクスのメモリー割り当て情報は、影響を受ける複数の処理のセットの特定を容易にする。

さらに異なる様態において、メモリー被疑部検出のためのコンピューター実施方法が提供される。本方法は、アプリケーションの複数の処理を特定する工程を含む。複数の処理は、複数の被疑メモリー割り当てに関連しており、さらに、少なくとも１つの所定の基準に基づいて特定される。少なくとも１つの所定の基準は、共有メモリー問題として識別されているクラス（classes known for common memory issues）、複数の以前の実行に起因するメモリー問題に関連するクラス、およびユーザー関心（user interest）に関連するクラスの１つ以上に関連する複数のメモリー割り当ての特定を含む。さらに、本方法は、複数の処理を系統的に実行し、複数のメモリー割り当て要求を開始する工程を含む。ここで、複数の処理を実行する工程は、メトリクスの生成をもたらす。１つの処理の実行において生成されたメトリクスは、少なくとも該１つの処理に関連するメモリー割り当て情報を含む。複数の処理のうちの１つの処理に関連するメモリー割り当て情報は、メモリー割り当てタイプと、タイムスタンプと、サイズと、メモリー割り当ての発端（origin of memory allocation）とを含む。生成されたメトリクスは、複数の処理を系統的に処理している間に、定期的に取得される。メトリクスを定期的に取得する工程は、複数のメモリー割り当て要求のそれぞれを、対応するユニーク識別子でタグ付けする工程を含む。ここで、複数のメモリー割り当て要求のうちの１つのメモリー割り当て要求に関連する対応するユニーク識別子は、対応する割り当てられたメモリー位置のハッシュコードと、該１つのメモリー割り当て要求に応答して作成されたオブジェクトのタイプと、オブジェクトの作成時のタイムスタンプと、ソース（ソースコード）および実行時間（source and runtime）におけるオブジェクトの位置とを含む。複数の処理のそれぞれに対応するメトリクスは、対応するユニーク識別子に関連している。複数の処理のセットは、複数の被疑メモリー割り当てによる影響を受ける複数の処理の中から、メトリクスおよび対応するユニーク識別子に基づいて、特定される。

さらに異なる様態において、複数のメモリー被疑部の検出のための方法を実行するためのコンピュータープログラムを有する（コンピュータープログラムが具体化された）非一時的コンピューター可読媒体が提供される。本方法は、アプリケーションの複数の処理を特定する工程を含む。複数の処理は、複数の被疑メモリー割り当てに関連しており、さらに、少なくとも１つの所定の基準に基づいて特定される。少なくとも１つの所定の基準は、共有メモリー問題として識別されているクラス、複数の以前の実行に起因するメモリー問題に関連するクラス、およびユーザー関心に関連するクラスの１つ以上に関連する複数のメモリー割り当ての特定を含む。さらに、本方法は、複数の処理を系統的に実行し、複数のメモリー割り当て要求を開始する工程を含む。ここで、複数の処理を実行する工程は、メトリクスの生成をもたらす。１つの処理の実行において生成されたメトリクスは、少なくとも該１つの処理に関連するメモリー割り当て情報を含む。複数の処理のうちの１つの処理に関連するメモリー割り当て情報は、メモリー割り当てタイプと、タイムスタンプと、サイズと、メモリー割り当ての発端とを含む。生成されたメトリクスは、複数の処理を系統的に処理している間に、定期的に取得される。メトリクスを定期的に取得する工程は、複数のメモリー割り当て要求のそれぞれを、対応するユニーク識別子でタグ付けする工程を含む。ここで、複数のメモリー割り当て要求のうちの１つのメモリー割り当て要求に関連する対応するユニーク識別子は、対応する割り当てられたメモリー位置のハッシュコードと、該１つのメモリー割り当て要求に応答して作成されたオブジェクトのタイプと、オブジェクトの作成時のタイムスタンプと、ソースおよび実行時間におけるオブジェクトの位置とを含む。複数の処理のそれぞれに対応するメトリクスは、対応するユニーク識別子に関連している。複数の処理のセットは、複数の被疑メモリー割り当てによる影響を受ける複数の処理の中から、メトリクスおよび対応するユニーク識別子に基づいて、特定される。

添付の図面を参照して詳細な説明が記述される。各図面中において、参照番号の左端の桁の数字は、その参照番号が最初に現れる図面の番号を示すものである。各図面において、同様の特徴およびモジュールに対して、一貫して同じ参照番号が用いられている。

図１は、本発明の実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のネットワーク実施を示す図である。

図２は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のためのシステムのブロック図である。

図３は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部を検出するための機能的フローを表す例を示す図である。

図４は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部を検出するためのメモリーモニタリングセッションを表す例を示す図である。

図５は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のための方法のフロー図である。

図６Ａは、別の例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のための方法のフロー図である。 図６Ｂは、別の例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のための方法のフロー図である。

本分野における当業者であれば、本発明の原理を具体化する図示のシステムおよびデバイスの概念図を表す任意のブロック図を適切に理解できるであろう。同様に、任意のフローチャート、フロー図等が、コンピューター可読媒体において実質的に表され、（明示的に示され、または、示されていない）コンピューターまたはプロセッサーによって実行される様々な処理を表すことは適切に理解されるであろう。

本発明は、アプリケーション環境における複数のメモリー被疑部の検出のためのシステムおよび方法に関する。本明細書において、「アプリケーション」は、１つ以上の機能ユニット（例えば、電子メール機能付きウェブポータル、データベースプログラム、文書処理プログラム、会計プログラム、数値解析プログラム）を含み得る「アプリケーションソフトウェア」を含む。また、「アプリケーション」は、１つの機能論理ユニット（例えば、データの変換、保存、および／または検索を担うデータベース管理サービスまたはデータベースアプリケーションプログラミングインターフェース（ＡＰＩ）サービスのような自律性ユニット）を含み得る「サービス」を含む。アプリケーションに関連するサービスは、アプリケーションによって提供される複数のユースケースまたは複数の処理に関連する様々なプログラムに関連していてもよい。例えば、オンラインチケット予約アプリケーションは、アプリケーションへのログイン、利用可能なチケットの検索、オンライン支払、ホテル予約、タクシー予約等の様々な処理およびユースケースのための複数のプログラムを含んでいる。いくつかの実施形態において、アプリケーションは、スタンドアローンＪａｖａ（登録商標）アプリケーションであってもよい。いくつかの実施形態において、アプリケーションは、複数のリソースを利用可能な複雑な業務用アプリケーションであってもよい。

アプリケーションに関連する様々なプログラムまたはユースケースが実行されている間に、アプリケーションは、プログラムのような一時的情報を、アプリケーションが実行されているシステムに関連するメモリーの一部分上に保存する必要がある。通常、システムの利用可能なメモリー量は制限されているため、１つのアプリケーションがシステムによって利用可能なメモリーの広範な部分を使用している場合、他のアプリケーションは、そのアプリケーションが必要とするメモリーにアクセスすることができない。このような状況を解決するため、アプリケーションは、アプリケーションに以前割り当てられたメモリーを解放する必要がある。特に、メモリーが解放されると、メモリーがシステムに再割り当てされ、さらに、システムは、このメモリーを、メモリーを要求する他のアプリケーションや同じアプリケーションの他のオブジェクトに割り当てることができる。メモリーの一部分のアプリケーションへの割り当ては、「メモリー割り当て（memory allocation）」または「オブジェクト割り当て（object allocation）」と称される。

いくつかの状況において、アプリケーションに割り当てられたメモリーが解放されず、アプリケーションが使用されるときであっても、アプリケーションに割り当てられたままとなる。このように、使用後にメモリーがクリーンアップされない状況を、「メモリーリーク（memory leak）」という。例えば、「飛行機予約」アプリケーションの場合、ユーザーがウェブサイトにログインすると、ユーザーのプロファイルがメモリーにロードされる。ログインすると、ユーザーは、検索、予約、支払等のような複数の処理を実行することができる。しかしながら、ユーザープロファイルおよびユーザープロファイルに関連するデータは、ユーザーがアプリケーションからログアウトするまで、有効なまま、メモリー内に保存されることとなる。この場合、ユーザープロファイルに関連するデータは、メモリー内に保存され続け、クリーンアップされない。このような状況も「メモリーリーク」とみなされる。メモリーリークは、時間経過に伴い蓄積され、さらに、この場合、メモリーリークがクリーンアップされない。このような状態は、システムの速度低下、長いアプリケーション応答時間およびメモリーエラーの発生をもたらす。したがって、効率的な応答時間のために、使用後にメモリーをクリーンアップする必要がある。

大規模アプリケーション／環境において、複数のメモリーリークに関連する複数のメモリー割り当てを特定することは、困難かつ多大な時間を必要とするものである。ここで、メモリーリークまたはメモリー問題に関連するメモリー割り当ては、「メモリー被疑部（memory suspects）」または「被疑メモリー（suspected memory）」と称することができる。複数のメモリー被疑部を特定するための方法の１つは、複数のメモリー被疑部のためにその後解析可能なメモリーヒープダンプを定期的に読み出す（retrieve）ことである。そのような複数のメモリーヒープダンプは、非常に大規模であることが多く、システムは、そのような複数の重いメモリーヒープダンプを処理することができないことが多い。別の方法においては、アプリケーションが複数のメモリー（またはオブジェクト）割り当て、例えば、ｎ番目のメモリー割り当ての全てをプロファイルするプロファイラーと共に使用され、適切なメモリー使用が判別される。このアプローチは、複数の重いオブジェクトを特定するが、いくつかのケースにおいて、メモリーリークに関連する根本原因および対応するユースケースが特定される。

いくつかの状況において、実行のために大量のメモリーを使用するアプリケーションの複数のオブジェクトが特定され得る。しかしながら、大部分のケースにおいて、メモリー管理ミスは、オブジェクトまたはオブジェクトが割り当てられたメモリー位置の特定に関連しているだけではなく、アプリケーションのユースケースにも関連している。これは、同じプログラム（または、コードや関数）が、メモリーに関連する１つより多いユースケース／状況で使用され得ることに起因する。例えば、「ソート（sorting）」に関するプログラムコードは、アプリケーションの互いに異なる複数のユースケースに関連する複数のソートアイテムにおいて利用される。

大部分の状況において、オブジェクトに対するメモリー割り当て、またはメモリー使用量は、アプリケーションコンテキスト（Application context）またはアプリケーションユースケースに特有のものである。よって、アプリケーションコンテキストを用いることなく検出された任意の複数のメモリー被疑部は、メモリーリーク問題を解決するためには不適切なガイダンスを提供する場合がある。本発明の様々な実施形態は、アプリケーションに関連する複数のメモリー被疑部の検出および解析のための複数のシステムおよび方法を開示する。様々な実施形態において、メモリーをモニタリングするための系統的なアプローチによって、アプリケーション環境内におけるメモリー使用、複数のアプリケーションユースケース、および複数の変更に基づいて、複数のメモリーの傾向（memory trends）を生成することができる。アプリケーション環境内における複数のメモリー被疑部の検出のためのシステムおよび方法の説明される様態は、任意の数の異なるデバイス、使用環境、および／または設定において実施可能であるが、実施形態は、以下の例示的なデバイスの文脈において記述される。

図１を参照すると、本発明の実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のためのネットワーク実施１００が図示されている。図示のネットワーク実施１００は、システム１０２と、ユーザーデバイス１０４−１、１０４−２、．．．１０４−Ｎのような複数のユーザーデバイスと、システム１０２とユーザーデバイス１０４−１、１０４−２、．．．１０４−Ｎとの間の通信を容易にするための通信ネットワーク１０６とを含んでいる。実施形態の１つにおいて、システム１０２は、アプリケーション環境における複数のメモリー被疑部の診断のための共通プラットフォームを容易にする。

本発明は、システム１０２が単一のデバイスとして実施されているものとして説明されるが、システム１０２は、ラップトップコンピューター、デスクトップコンピューター、ノートパソコン、ワークステーション、メインフレームコンピューター、ネットワークサーバー、タブレット、携帯電話、ロボット等の様々な演算システムとして実施可能であることは、理解されるであろう。

システム１０２は、１つ以上のユーザーデバイス１０４−１、１０４−２、．．．１０４−Ｎ（以下、集合的にユーザーデバイス１０４という）またはユーザーデバイス１０４上のアプリケーションを介して、複数のユーザーによってアクセスされ得ることは理解されるであろう。ユーザーデバイス１０４の例としては、これに限定されるものではないが、携帯型コンピューター、ＰＤＡ、携帯型デバイス、ワークステーションが挙げられる。アプリケーションセッションを実行するため、ユーザーデバイス１０４は、サーバー１０８と、対応するセッションを確立することができる。

実施形態の１つにおいて、各デバイス１０４は、サーバー１０８と通信を行うため、サーバー１０８とのセッションを確立することができる。デバイス１０４は、通信ネットワーク１０６を介して、サーバー１０８と通信を行うことができる。通信ネットワーク１０６は、無線ネットワーク、有線ネットワーク、またはこれらの組み合わせであってもよい。通信ネットワーク１０６は、異なるタイプのネットワーク（例えば、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット等）の１つとして実施することができる。通信ネットワーク１０６は、専用ネットワークであっても、共有ネットワークであってもよい。共有ネットワークは、様々なタイプのプロトコル（例えば、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、トランスミッションコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）等）を用いて、互いに通信を行う異なるタイプのネットワークの接続を意味する。さらに、通信ネットワーク１０６は、様々なネットワークデバイス（ルーター、ブリッジ、サーバー、演算デバイス、記憶デバイス等）を含んでいてもよい。

複数のメモリー被疑部の検出は、アプリケーションのメモリーを定期的にモニタリングし、さらに、実行中のメモリー（live memory）内のメモリーからの複数の出力を収集することにより実行可能である。メモリーのモニタリングは、被疑メモリーの位置を探し出す（isolate）ことを容易にし、さらに、アプリケーションのユースケースを参照して、複数の被疑メモリー割り当てを関連付ける。特に、システムは、様々なメモリーモニタリングセッションにおいてメモリーをモニタリングし、アプリケーションに関連するメモリー使用量、ガベージ収集（garbage collections：用済みになったメモリーブロックの検出・解放機能）、関連ユースケースを含むメトリクスを判別する。システムは、判別されたメトリクスに基づく複数のメモリー傾向の生成を容易とする。いくつかの実施形態において、ユーザーは、ユーザーデバイス（またはクライアント）１０４を用いて、サーバー１０２上で実行されているアプリケーション用のメモリーモニタリングセッションを開始することができる。その他のいくつかの実施形態において、メモリーモニタリングは、定期的に、自動的に開始されてもよい。

クライアント、例えば、デバイス１０４は、サーバー１０２とのメモリーモニタリングセッションを確立することができる。メモリーモニタリングセッションの間、サーバー１０８上のＪＶＭ上で実行されているアプリケーションに関連する様々なユースケースが系統的に実行されている制御された環境において、アプリケーションがモニタリングされる。メモリーモニタリングセッション中に生成されたメトリクスは、スナップショット（snapshot）として収集される。例えば、サーバー１０８に含まれるシステムは、クライアント１０４からメモリーモニタリングセッションを実行するユーザーによる解析のために、メモリーモニタリングセッションのメトリクスを記録および保存することができる。いくつかの実施形態において、メトリクスは、サーバー１０８上のメモリー内に保存される。いくつかの実施形態において、システム１０２は、ユーザーによる解析のために、クライアント１０４にデータを送信することができる。クライアント１０４は、デバイス１０４上に表示されたグラフィカルユーザーインターフェース（ＧＵＩ）内に、ＪＶＭ上で実行されているアプリケーション用に記録されたデータを表示することができる。複数のメモリースナップショットまたはメトリクスの収集は、ユーザーによって始動されてもよいし、自動設定されたものであってもよい。複数のメモリースナップショットは、ユースケース毎にカテゴリー分けすることができ、さらに、ユースケースまたはビジネス処理を特定するための関連アプリケーションコンテキスト（relevant application context）を含んでいる。システム１０２は、アプリケーションのメモリー診断のために、複数のメモリースナップショットを比較し、さらに、複数の以前のスナップショットを用いて複数のメモリースナップショットを検証することができる。複数のメモリー被疑部の検出のためのシステムの例が、図２を参照してさらに説明される。

図２は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部の検出のためのシステム２００のブロック図である。システム２００は、図１のシステム１０８の例である。例示的な実施形態において、システム２００は、演算デバイス内において実施することができる。代替的に、システム２００は、サーバー（例えば、図１のサーバー１０８）内において実施することができる。実施形態の１つにおいて、システム２００は、アプリケーションの様々な処理またはユースケースに関連するメモリー割り当てをモニタリングすることを容易にし、さらに、メモリーのモニタリング中に生成されたメトリクスの解析に基づく複数のメモリー被疑部の検出を容易にする。システム２００は、プロセッサー２０２のような少なくとも１つのプロセッサーと、メモリー２０４のような少なくとも１つのメモリーと、ユーザーインターフェース２０６とを含む、または、これらと通信している。実施形態の１つにおいて、プロセッサー２０２、メモリー２０４、およびユーザーインターフェース２０６は、システムバス２０８のようなシステムバスや同様の機構によって互いに接続されている。

プロセッサー２０２は、回路実施、特に、通信に関連する音声および論理機能を含む。例えば、プロセッサー２０２は、これに限定されるものではないが、１つ以上のデジタル信号プロセッサー（ＤＳＰｓ）、１つ以上のマイクロプロセッサー、１つ以上の特殊用途コンピューターチップ、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、１つ以上の特定用途向け集積回路（ＡＳＩＣｓ）、１つ以上のコンピューター、様々なアナログ−デジタルコンバーター、デジタル−アナログコンバーター、および／またはその他のサポート回路を含む。また、プロセッサー２０２は、メッセージおよび／またはデータ、または情報をエンコード化（暗号化）する機能を含んでいてもよい。プロセッサー２０２は、特に、プロセッサー２０２の動作をサポートするよう構成されたクロック、演算論理ユニット（ＡＬＵ）、および論理ゲートを含んでいてもよい。さらに、プロセッサー２０２は、メモリー２０４またはプロセッサー２０２がアクセス可能な他の媒体内に保存された１つ以上のソフトウェアプログラムを実行する機能を含んでいてもよい。

メモリー２０４のような少なくとも１つのメモリーは、システムの機能を実行するためにシステムによって用いられる複数の情報またはデータを保存している。例えば、例示的な実施形態において、メモリー２０４は、アプリケーションの複数のメモリーモニタリングセッションの間に生成されたメトリクスを保存するよう構成されている。メモリー２０４は、例えば、揮発性メモリーおよび／または不揮発性メモリーを含む。揮発性メモリーの例としては、これに限定されるものではないが、揮発性ランダムアクセスメモリー（ＲＡＭ）が挙げられる。不揮発性メモリーは、追加的または代替的に、電気的消去可能プログラム可能リードオンリーメモリー（ＥＥＰＲＯＭ）、フラッシュメモリー、ハードドライブ等を含む。揮発性メモリーのいくつかの例としては、これに限定されるものではないが、ランダムアクセスメモリー、ダイナミックランダムアクセスメモリー、スタティックランダムアクセスメモリー等が挙げられる。非揮発性メモリーのいくつかの例としては、これに限定されるものではないが、ハードディスク、磁気テープ、光ディスク、プログラム可能リードオンリーメモリー、消去可能プログラム可能リードオンリーメモリー、電気的消去可能プログラム可能リードオンリーメモリー、フラッシュメモリー等が挙げられる。メモリー２０４は、システム２００が、メモリー診断のための複数のメモリー割り当て、アプリケーション、命令等のモニタリングに関する情報、データを保存し、様々な例示的な実施形態に係る様々な機能を実行可能とするよう構成されている。追加的または代替的に、メモリー２０４は、プロセッサー２０２によって実行されたときに、システム２００を様々な実施形態において記述されたような様態の動作を実行させる複数の命令を保存するよう構成されていてもよい。

実施形態の１つにおいて、システム２００は、アプリケーションを開始するよう構成されている。例えば、システム２００は、ユーザー入力に基づいて、アプリケーションを開始するよう構成されている。アプリケーションを開始する際に、複数のメモリー割り当て要求（またはオブジェクト）が、実行時（ランタイム）環境において生成される。この複数のオブジェクトは、複数のメモリー位置のそれぞれに割り当てられる。複数のオブジェクトへのメモリーの割り当ては、以下、「メモリー割り当て」または「オブジェクト割り当て」と称される。アプリケーションに関連する複数のメモリー被疑部を判別するため、メモリーのプロファイリングが実行される。アプリケーションに関連するメモリーのプロファイリングまたはメモリープロファイリングは、プログラム動作（program’s behavior）を調査および解析し、プログラムのメモリー使用をどうやって最適化するかを判別するための処理を含む。

実施形態の１つにおいて、システム２００は、アプリケーションに関連するメモリーのプロファイリングを実行するよう構成されている。実施形態の１つにおいて、システム２００は、メモリープロファイリングを実行するため、アプリケーション環境に統合（integrate）されたプロファイラーエージェントまたはプロファイラーを含んでいる。プロファイラーエージェントは、プロセッサーによって設定される。プロファイラーエージェントは、エージェントとして動作するコンポーネントであり、アプリケーションからの全ての関連メトリクスを収集し、メトリクスをデータストア（data store）に保存する。プロファイラーエージェントは、ターゲットアプリケーション内にバイナリー実行論理（binary execution logics）を挿入し（inject）、それにより、アプリケーションから実行時環境への複数のメモリー割り当て要求を追跡することができる。例えば、Ｊａｖａベースのアプリケーション用に、プロファイラーエージェントは、ＢＣＩ（Byte Code Instrumentation）技術を用いて、自身をアプリケーション内に組み込ませることができる。必要に応じて、ＢＣＩを用いて、サンプルＪａｖａアプリケーションが変換することにより、メトリクスを収集することができる。

実施形態の１つにおいて、プロファイラーがメモリープロファイリングに必要な関連データ（またはメトリクス）を収集することを可能とするために、システム２００は、アプリケーションの複数のクラスおよび複数のバイナリーデータを変換するよう構成されている。実施形態の１つにおいて、実行時環境において、ターゲットアプリケーションが開始され、さらに、複数のクラスがクラスローダー（class loader）によってロードされると、システム２００は、ロードされている複数のクラスおよび複数のバイナリーデータが少なくとも１つの所定の基準を満たしているか否かの判別に基づいて、複数のクラスおよび複数のバイナリーデータを変換するよう構成されている。例えば、ｘ_ｉが実行時にクラスローダーによってロードされるべき複数のクラス（バイナリーデータ）を表す場合、その後、複数のクラスがロードされている間に、プロファイラーエージェントが、全てのクラスのロードを中断（intercept）し、以下の所定の基準／条件のチェックを行う。
ｘ_ｉ∈Ｘ_ｎｆ
ここで、Ｘ_ｎｆは、所定の基準を満たす複数のクラスのセットである。実施形態の１つにおいて、所定の基準を満たす複数のクラスのセットは、メモリープロファイリングに用いられる複数のネイティブフィルター（native filter）を含む。ここで、複数のネイティブフィルター（Ｘ_ｎｆ）は、以下に述べるセットの１つ以上として定義することができる。
Ｘ_ｎｆ＝ユーザー関心の複数のバイナリーデータ／クラスの特定のセット、および／または
共有メモリー問題として識別されている複数のバイナリーデータ／クラスの特定のセット、および／または
複数の以前の実行に起因する複数のメモリー問題に基づく複数のアプリケーション特有バイナリーデータ／クラスの特定のセット

実施形態の１つにおいて、システム２００は、メモリープロファイリングのために複数のクラスバイト(class bytes)をＪａｖａエージェントに提供する前に、プロファイラー変換（ＰＴ：Profiler Transformation）を、所定の基準を満たす複数のメモリー割り当て要求（または複数のクラス）に実行するよう構成されている。プロファイラー変換は、以下のように表すことができる。

上に示されているように、プロファイラー変換の実行は、システム２００に、複数のメモリー割り当て要求を、対応するユニーク識別子でタグ付けさせる工程を含んでいる。実施形態の１つにおいて、ユニーク識別子は、メモリー割り当て要求に関連する割り当てられたメモリーのハッシュコードに基づいて生成される。実施形態の１つにおいて、以下のように定義される関数を用いて、複数のオブジェクトのユニーク番号を作成およびタグ付けすることにより、複数のオブジェクトをタグ付けすることができる。
ユニーク番号生成Ｕ＝ｆ（タイプ、メモリー、時間、位置）
ここで、
「タイプ」は、作成されるオブジェクトのタイプであり、
「メモリー」は、オブジェクトのメモリー位置であり、
「時間」は、オブジェクトが作成時／割り当て時のナノ秒単位のタイムスタンプであり、
「位置」は、ソースおよび実行時間（source and runtime）におけるオブジェクトの位置である。

オブジェクトの位置は、以下の関数として定義することができる。
位置＝ｆ（スレッド、クラス、クラスローダー、メソッド、行番号）
ここで、
「スレッド（thread）」は、実際にオブジェクトの作成／割り当てを実行したスレッドであり、
「クラス」は、割り当てが発生したクラスの（パッケージ名を含む）完全修飾クラス名（fully qualified class name）であり、
「クラスローダー」は、完全修飾クラスをロードするために用いられたクラスローダータイプであり、
「メソッド（method）」は、オブジェクト割り当てが発生したメソッド名（メソッドのシグネチャー）であり、
「行番号」は、割り当てが発生した行番号である。

上記定義に基づいて、システム２００は、複数のオブジェクトをタグ付けするために利用可能な複数のユニーク番号／識別子を作成するよう構成されている。上記関数は、複数の静的パラメーターおよび複数の動的パラメーターに基づいて複数のオブジェクトを区別可能とするよう作成されている。例えば、オブジェクトがループ内で作成されたとしても、すなわち、同じ行番号／クラスのオブジェクトが複数作成されたとしても、どのクラスローダーが用いられたのか、どのタイムスタンプでオブジェクトが作成されたのか、または、どのスレッドが用いられたのかに基づいて、同じ行番号／クラスの複数のオブジェクトを区別することができる。

例示的な実施形態において、システム２００は、タグ付けされた複数のメモリー割り当て要求に関連する詳細を有するメトリクスを生成するよう構成されている。例えば、メトリクスは、タグ付けされた複数のメモリー割り当てに関連する割り当て要求の発端、タイムスタンプ、サイズ、タイプ等のような情報を含むマッピングテーブルの形式で取得される。変換下の複数のオブジェクトは、割り当てのソースに関するマッピングテーブルでタグ付けされる。任意のタイミングにおいて、オブジェクトがもはや使用されていないとシステムが判断した場合（割り当て解除／ガベージ収集の際）、メトリクス（またはマッピングテーブル）内において、このオブジェクトの詳細が更新される。さらに、システム２００は、全体のメモリー使用量、メモリー空き容量、メモリー読み出しに費やされる時間、メモリー読み出しに費やされるＣＰＵのようなメモリー情報を定期的に取得するよう構成されている。

実施形態の１つにおいて、システム２００は、少なくともメモリー割り当て／割り当て解除に関するアプリケーションユースケースとともに、メモリーの割り当て／割り当て解除に関するメモリー情報を保存するよう構成されている。実施形態の１つにおいて、システム２００は、メモリー情報を自動的かつ定期的に保存するよう構成されている。異なる実施形態において、システム２００は、ユーザー入力に基づいてメモリー情報を保存するよう構成されている。例えば、ユーザーは、プロファイラーエージェントに対し信号を発行し、メトリクスをメモリー２０４（またはメトリクスデータストア）に保存する。メトリクスは、メモリースナップショットと称することができる。メモリースナップショットは、アプリケーションメモリー情報と、メモリー割り当て情報とを含む。アプリケーションメモリー情報は、これに限定されるものではないが、実行時環境用の合計メモリー使用量、アプリケーションによって使用されるメモリー、メモリーをクリーンアップするために実行時環境によって為される試行（attempts）（例えば、Ｊａｖａ環境におけるガベージ収集カウント）、メモリーをクリーンアップするためにプロセッサーによって費やされる時間（例えば、Ｊａｖａ環境におけるガベージ収集に費やされる時間）、およびメモリースナップショットのタイムスタンプを含んでいてもよい。メモリー割り当て情報は、メモリー割り当てタイプ（構造、クラス等）、タイムスタンプ、サイズ、割り当ての発端（例えば、関数、ソース等）のような情報を含んでいる。

実施形態の１つにおいて、システム２００は、被疑メモリーを検出するために、メモリーモニタリングセッションにおけるアプリケーションを系統的にモニタリングするよう構成されている。ここで、用語「系統的なモニタリング」とは、アプリケーションに関連する複数のユースケースまたは複数の処理を反復して実行することにより、アプリケーションをモニタリングすることを意味する。ここで、複数のユースケースは、所定の基準を満たす複数のクラスに関連するユースケースである。実施形態の１つにおいて、アプリケーションを系統的にモニタリングする工程は、複数の特定のターゲットユースケースを用いて、ターゲットアプリケーションにアクセスする工程を含む。例えば、ユーザーは、メモリーモニタリングセッション中に、複数の特定のターゲットユースケースを用いて、ターゲットアプリケーションに定期的にアクセスする。実施形態の１つにおいて、ターゲットアプリケーションのモニタリングは、システム２００のユーザーインターフェースから実行可能となっている。例えば、ユーザーは、システムのユーザーインターフェース（または、図１のデバイス１０４のようなクライアントデバイス）から、ターゲットアプリケーションのモニタリングを開始することができる。異なる実施形態において、システム２００は、メモリーモニタリングセッション中に、複数の特定のターゲットユースケースを用いて、ターゲットアプリケーションに定期的にアクセスするよう自動設定されていてもよい。

実施形態の１つにおいて、システム２００は、メモリーモニタリングセッションの開始時および終了時に、複数のメモリースナップショットを取得するよう構成されている。メモリーモニタリングセッションの開始時および終了時に取得されるこのような複数のメモリースナップショットは、ベースラインスナップショットと称される。複数のアプリケーションユースケースは、メモリーモニタリングセッション中に、複数回反復して繰り返し実行される。各反復の終了時において、システム２００は、メモリースナップショットを取得するよう構成されている。メモリーモニタリングセッション中の複数のメモリースナップショットの生成の例が、図４を参照して説明される。実施形態の１つにおいて、逆変換が適用され、モニタリングが完全に止められ、アプリケーションがオリジナル状態に戻る。実施形態の１つにおいて、モニタリングセッションを終了させるために、システム２００は、逆変換（逆プロファイル変換とも称される）を実行するよう構成されている。逆プロファイル変換ＰＴ’（ｘ_ｉ）は、以下のように定義される。

メモリーモニタリングセッション中に、システム２００は、メモリーモニタリングセッション中に生成された複数のメモリースナップショットを保存するよう構成されている。例示的な実施形態の１つにおいて、システム２００は、システム２００のメモリー内に複数のメモリースナップショットを保存するよう構成されている。実施形態の１つにおいて、複数のメモリースナップショットを、システム２００に関連するデータストア内に保存することができる。ここで、データストアは、システム２００に通信可能に接続されている。

システム２００は、複数のメモリースナップショットを、ユースケースまたはビジネス処理毎にグループ化するよう構成されている。変換下にある全てのオブジェクトが、割り当ての発端についてのマッピングテーブルを用いてタグ付けされるので、システム２００は、複数のメモリースナップショットをユースケース毎にグループ化することができる。実施形態の１つにおいて、システム２００は、ユニーク識別子でタグ付けされた複数のメモリー割り当てを特定するよう、実行時メモリーを構文解析（parse）するよう構成されている。したがって、メモリースナップショットに関連する複数のその他メトリクスと共に、割り当てリストをメモリー内に追加（populate）することができる。

システム２００は、複数のメモリー被疑部を検出するために、複数のスナップショットの解析を実行するよう構成されている。実施形態の１つにおいて、システム２００は、複数のベースラインスナップショットと複数の中間スナップショットとの比較に基づいて、解析を実行するよう構成されている。複数のベースラインスナップショットと複数の中間スナップショットとの比較は、複数のオブジェクトの各タイプ／クラスのサイズ、カウントにおける変化を取得するよう実行される。

実施形態の１つにおいて、モニタリングセッション中に取得された複数のメモリースナップショットに基づいて、メモリーリークを引き起こす問題があると疑われる（problematic）複数のユースケースを検出することができる。例示的な実施形態において、システム２００は、メモリーモニタリングセッション中に取得されたメトリクスに対する解析を実行し、さらに、合計サイズおよびカウントに基づいてトップＮメモリー割り当てタイプの複数のメモリー傾向を提供するよう構成されている。実施形態の１つにおいて、システム２００は、複数のメモリースナップショットに渡るメトリクスを構文解析し、さらに、メモリー被疑部リストを生成する。メモリー割り当てタイプ（例えば、構造、クラス等）、タイムスタンプ、サイズ、割り当ての発端（関数／ソースコード）のようなメモリー割り当て情報内の各項目のために、様々なメモリースナップショット間で比較が実行され、複数のオブジェクトの各タイプ／クラスのサイズ、カウントにおける変化が判別される。実施形態の１つにおいて、システム２００は、ベースライン開始時と終了時のスナップショットを比較して、全体のメモリーサイズまたはカウントが純増している全てのオブジェクトタイプのグラフィックパターンを生成するよう構成されている。実施形態の１つにおいて、システム２００は、グラフに沿った複数の点を考慮することによりグラフの傾きを算出するよう構成されている。高い正の平均傾き値（average slope value）を有し、負の傾きを有さない複数のオブジェクトタイプを降順にリストすることができる。傾きがゼロ、負、または、最終的な負の傾向（net trend of negative）を有する正と負の組み合わせである場合、これらはメモリー被疑部としてカテゴリー分けされない。一方、傾きが線形であり、かつ、傾きが正または最終的な組み合わせ平均傾き（net combined average slope）が正である場合、対応するタイプがメモリー被疑部の候補となる。

実施形態の１つにおいて、システム２００は、メモリー被疑部リスト内の頻出（frequent）メモリー被疑部として識別されている複数のオブジェクトタイプ（複数の以前の実行に起因する複数の一般的な実行時／アプリケーション特有問題）をハイライト（強調）するよう構成されている。複数のメモリー被疑部の選択時において、詳細な掘り下げ（drill down）レポートを、スタック追跡および相関グラフと共に表示することができる。相関グラフは、オブジェクトメモリーサイズ／カウントグラフと、その他のメモリー詳細（ユースケース毎のオブジェクトタイプのメモリー傾向の相関ビューを得るための合計メモリー使用量、合計メモリー空き容量、ガベージ収集時間を含む）とを有する多層構造のグラフである。また、相関グラフは、メモリーをクリーンアップするのに費やされる時間（ガベージ収集時間）を表示するので、メモリー被疑部によるＣＰＵまたは応答時間への影響も表示することができる。

例示的な実施形態において、根本原因位置（コードスタックトレース）、アプリケーションコンテキスト（特に、原因に関与しているユースケース）の探索の際に、システム２００は、アプリケーションの複数の被疑位置についての複数のレポートを生成するよう構成されている。複数のメモリー被疑部が修正されると、メモリー問題が解決されたかどうかをチェックするために、同じユースケースが再度モニタリングされ、以前のスナップショットとの比較が実行される。

図３は、アプリケーション（例えば、例示的な実施形態に係るアプリケーション３０２）に関連する複数のメモリー被疑部を検出するための機能フロー３００の例を示している。機能フローは、アプリケーション３０２、設定データ３０４、メトリクスデータストア３０６、メモリー被疑部解析部３０８、ユーザーインターフェース３１０、およびアプリケーション３１２に関連するプロファイラーエージェント３１２を含む様々なブロック間のフローを含むよう図示されている。

ここでいうアプリケーション３０２は、複数のユースケースを含み得るターゲットアプリケーションを意味する。例えば、ターゲットアプリケーションは、オンラインチケット予約アプリケーションであってもよい。チケット予約アプリケーションに関連する複数のユースケースまたは複数の処理は、例えば、飛行機の検索、飛行機の予約、フライトの再スケジューリング等を含んでいる。

アプリケーション３０２に関連する複数のメモリー被疑部を取得するために、プロファイラーエージェント３１２がアプリケーション３０２に取り付けられる。プロファイラーエージェント３１２は、アプリケーション３０２に関連するメモリーを系統的にプロファイリングし、さらに、アプリケーションに関連する関連データ（例えば、メトリクス）を定期的に収集するよう構成されている。設定データ３０４は、メトリクスの取得に関する入力を含んでいる。例えば、設定データ３０４は、メトリクス内において取得されるべきデータが何であるか、いつデータを取得すべきか等の情報を含んでいる。実施形態の１つにおいて、設定データ３０４は、ユーザーによって提供されてもよく、さらに、アプリケーションをモニタリングするメモリーモニタリングセッションを開始する前に保存されてもよい。実施形態の１つにおいて、自動生成された複数の初期（デフォルト）設定が用いられてもよい。

プロファイラーエージェント３１２によって収集されるメトリクスが、メトリクスデータストア３０６内に保存される。例えば、メトリクスデータストア３０６は、複数の処理に関連するメモリー割り当て情報およびメモリー情報を保存することができる。メトリクスデータストア３０６は、メモリー被疑部解析部３０８に接続されている。メトリクスデータストア３０６において収集されたメトリクスは、メモリー被疑部解析部３０８に提供される。メモリー被疑部解析部３０８は、複数のメモリー被疑部の原因となる関連アプリケーションコンテキスト（または、ユースケース、処理）と共に、アプリケーションに関連する複数のメモリー被疑部を予測するためのデータを解析するよう構成されている。

実行される複数の状況／処理に基づいて、ユーザーインターフェース３１０は、急増大しているメモリーのメモリー傾向を示す解析を表示するよう構成されている。さらに、この解析は、メモリーリークに関連するメモリー位置と、メモリーリークの発生の原因となっているコード（または関数）と、メモリーリークの発生の原因となっているコードに関連する特定のユースケースとを示す。また、ユーザーインターフェース３１０は、ユーザーが、メトリクスの取得に関する複数の入力を提供できるようにしてもよい。例えば、ユーザーは、複数の特定の時間インスタンス（instances of time）におけるメトリクスまたはメモリースナップショットを取得することに関心を有し、そのため、複数の入力をユーザーインターフェースで提供してもよい。実施形態の１つにおいて、ユーザーは、複数のメモリー被疑部を判別するために、ユーザーインターフェース３１０から、メモリーモニタリングセッションを開始する。メモリーモニタリングセッション中に、メトリクスを取得する。メモリーモニタリングセッションの例が、図４を参照してさらに説明される。

図４は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部を検出するためのメモリーモニタリングセッションの例示的表示４００を示している。本発明において、メモリーモニタリングセッションを、アプリケーションに関連する複数のメモリー被疑部を検出するために、その最中にアプリケーションに関連する複数の処理が系統的に実行されるセッションとして定義することができる。

実施形態の１つにおいて、アプリケーションが開始され、アプリケーションに関連するメトリクスが取得される。実施形態の１つにおいて、複数の第１のベースラインスナップショットが、４１０で示されるシーケンスに従うことにより、アプリケーションに関連する処理のために取得される。図４中のシーケンス４１０を参照すると、アプリケーションの開始時に、メトリクス（または、４０２で示されているメモリースナップショット）が取得される。このような、アプリケーションの開始時に取得されるメトリクス４０２は、ベースラインメモリースナップショットと称される。モニタリングセッションが開始され、第１の処理４０４が実行される。実施形態の１つにおいて、第１の処理４０４は、ログイン処理である。ログイン処理４０４を実行中に、アプリケーションに関連するメトリクス（またはメモリースナップショット）４０６が取得される。ログアウト処理（例えば、ログアウト処理４０８）である第２の処理が実行され、アプリケーションに関連するメトリクス４１２が取得される。メトリクスに関連する様々なパラメーターの増加または減少が、メトリクス４０２、４０６、および４１２の比較に基づいて判別される。実施形態の１つにおいて、判別されたサイズまたは他のパラメーターの変化が、グラフィック形式（例えば、ユーザーインターフェース上におけるグラフィック形式）で提供され得る。例えば、ログインまたはログアウト処理の後、メモリーの増加または減少を示すグラフを表示することができる。実施形態の１つにおいて、ログイン、メトリクス取得、ログアウト、および再度のメトリクス取得からなるシーケンス４１０が複数回繰り返される（複数回反復される）。複数回の複数の処理を実行する工程と、メトリクスを取得する工程とを含む複数回の反復を実行する工程の例が、シーケンス４５０を参照してさらに説明される。

図４のシーケンス４５０を参照すると、アプリケーションが開始され、アプリケーションに関連するメトリクス４５２（またはベースラインスナップショット４５２）が取得される。メモリーモニタリングセッションが開始され、第１の処理４５４が実行される。実施形態の１つにおいて、第１の処理は、ログイン処理、例えば、ログイン処理４５４である。ログイン処理４５４を実行中に、アプリケーションに関連するメトリクス（またはメモリースナップショット）４５６が取得される。処理、例えば、処理４５８が実行され、処理の実行中に、アプリケーションに関連するメトリクス４６０が取得される。処理は、アプリケーションのユースケースに関連していてもよい。例えば、オンライン予約アプリケーションにおいて、処理４５８は、チケット検索処理であってもよい。図４に示されているように、処理は複数回実行され、各処理の実行後に、メモリースナップショットが生成される。例えば、処理４５８が複数回実行され、各処理の実行後に、メモリースナップショット４６０、４６２、および４６４のようなメトリクスが取得される。メモリーモニタリングセッションの終了の少し前に、ログアウト処理（例えば、ログアウト処理４６６）である第２の処理が実行され、アプリケーションに関連するメトリクス４６８が取得される。

実施形態の１つにおいて、シーケンス４１０およびシーケンス４５０において取得された複数のスナップショットに基づいて、メモリーリークを引き起こす問題があると疑われる複数のユースケースが検出される。例示的な実施形態において、システムは、図２を参照して説明したように、メモリーセッション中に取得された複数のメトリクスに対する解析を実行し、さらに、複数のメモリー被疑部を提供するよう構成されている。実施形態の１つにおいて、シーケンス４１０および４５０の実行中に収集されたメトリクスが、複数のメモリー被疑部を検出するために解析される。複数のメモリー被疑部の診断を説明する例示的なフローチャートが図５を参照して説明される。

図５は、例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部を検出するための方法５００のフロー図を示している。方法５００は、コンピューター実行可能命令の一般的なコンテキストで説明される。一般的に、コンピューター可読命令は、特定の機能を実行、または特定の抽象データ型（abstract data type）を実施するルーティーン（routines）、プログラム、オブジェクト、コンポーネント、データ構造体、プロシージャー(procedures)、モジュール、関数等を含む。また、方法５００は、通信ネットワークを介してリンクされた複数の遠隔演算デバイスによって機能が実行される分散型演算環境（distributed computing environment）内において実施されてもよい。分散型演算環境内では、コンピューター実行可能命令は、ローカルコンピューター記憶媒体およびメモリー保存デバイス等の遠隔コンピューター記憶媒体の双方内に位置していてもよい。

ここで説明される方法５００の順番は、限定を構成する意図はなく、任意の数の説明される方法ブロックが、任意の順番で組み合され、方法５００または代替的方法を実施してもよい。さらに、個々のブロックが、ここに説明される本発明の原理および範囲から逸脱することなく、方法５００から削除されてもよい。さらに、方法５００は、任意の適切なハードウェア、ソフトウェア、ファームフェア、およびこれらの組み合わせにおいて実施することができる。しかしながら、説明の簡略化のため、以下に説明される実施形態では、方法５００は、上述のシステム１０２（図１）および／またはシステム２００（図２）において実施されているものとして考える。

５０２において、アプリケーションに関連する複数の処理が系統的に実行される。実施形態の１つにおいて、複数の処理の実行は、メトリクスの生成をもたらす。このメトリクスは、処理に関連付けられたメモリー割り当て情報およびアプリケーションメモリー情報を含む。５０４において、複数の処理を系統的に実行している間に生成されたメトリクスが定期的に取得される。複数の処理を系統的に実行する工程および定期的にメトリクスを取得する工程の例は、図４を参照して説明された。

５０６において、定期的に取得されたメトリクスに基づいて、複数の被疑メモリー割り当による影響を受ける複数の処理の中から、複数の処理のセットが検出される。実施形態の１つにおいて、メトリクスのメモリー割り当て情報は、影響を受ける複数の処理のセットの特定を容易にする。アプリケーションに関連する複数のメモリー被疑部を検出するための方法の詳細なフロー図が図６を参照してさらに説明される。

図６は、別の例示的な実施形態に係るアプリケーションに関連する複数のメモリー被疑部を検出するための方法６００のフロー図を示している。

６０２において、アプリケーションが開始される。アプリケーションは、アプリケーションにアクセスするために利用されるデバイスのユーザーインターフェースを介して、ユーザーによって開始されることができる。６０４において、少なくとも１つの所定の基準を満たすアプリケーションに関連する複数のクラスおよび／またはバイナリーデータが変換される。実施形態の１つにおいて、所定の基準は、共有メモリー問題として識別されているクラス、複数の以前の実行に起因するメモリー問題に関連するクラス、およびユーザー関心に関連するクラスの少なくとも１つのクラスに関連する複数のメモリー割り当ての特定を含む。実施形態の１つにおいて、所定の基準は、複数の被疑メモリー割り当てに関連付け可能なアプリケーションの上述の複数の処理を特定するために設定されていてもよい。

６０６において、複数のメモリー被疑部を検出するために、メモリーモニタリングセッションが確立される。メトリクスを収集するためのメモリーモニタリングの例は、図４を参照して詳細に説明された。メモリーモニタリングセッションの間、アプリケーションに関連する少なくとも１つの処理が反復して実行され、さらに、各実行の後に、メモリーに関連するメトリクスが取得される。このようなメトリクスは、メモリースナップショットと称される。例えば、６０８において、アプリケーションに関連する第１の処理が、モニタリングセッションの開始時に実行される。６１０において、第１の処理に対応するメモリー割り当て要求が、対応するユニーク識別子でタグ付けされる。６１２において、第１の処理に関連するメトリクスが取得される。このような、メモリーモニタリングセッションの開始時に取得されるメトリクスまたはメモリースナップショットを、ベースメモリースナップショットと称することができる。６１４において、アプリケーションに関連する複数の処理が複数回実行される。６１６において、複数の処理に対応する複数のメモリー割り当て要求が、複数の対応するユニーク識別子でタグ付けされ、複数の処理の各処理の実行後に、メトリクスが取得される。

６２０において、第２の処理が実行され、メモリーモニタリングセッションが停止される。６２２において、第２の処理に対応するメモリー割り当て要求が、対応するユニーク識別子でタグ付けされる。６２４において、第２の処理に関連するメトリクスが取得される。６２６において、複数の処理の実行において生成されたメトリクスが追加される。実施形態の１つにおいて、複数の処理の対応する処理に関連するメトリクスが保存されているテーブル（表）に、生成されたメトリクスが追加される。実施形態の１つにおいて、複数の処理に対応する複数のメモリー割り当て要求をタグ付けするために用いられたユニーク識別子に基づいて、メトリクスが、複数の対応する処理に関連付けられる。６２８において、解析が実行され、複数の対応する処理と、定期的に取得されるメトリクスの比較に基づいて、複数の被疑メモリー割り当てに関連する複数のメモリー傾向を判別することができる。実行可能な様々な例示的な解析が、図２を用いて説明された。

上記の記述は、本分野における当業者が本発明を実施および使用することを可能とするために、本発明を説明するものである。本発明の範囲は、特許請求の範囲によって規定され、本分野における当業者が想到し得るその他の変形例を含む。そのようなその他の変形例が特許請求の範囲の文言と変わらない同等の要素を有するか、特許請求の範囲の文言と実質的に変わらない同等の要素を含んでいるのであれば、そのようなその他の変形例は、特許請求の範囲の権利範囲内に含まれる。

本明細書の様々な実施形態は、メモリー被疑部検出のための方法およびシステムを提供する。メモリー被疑部は、問題があると疑われる、および／または、エラーと関連していると疑われるメモリー位置である。例えば、システムは、複数の被疑メモリー割り当てによる複数のメモリーエラーや遅い応答時間を解決するためものである。このような問題は、アプリケーション／サーバー／サードパーティーコンポーネントの移行／更新等の際に観測される。大規模アプリケーション／環境に置いて、このようなメモリーの特定は困難かつ多大な時間を必要とするものである。本発明の様々な実施形態は、メモリーをモニタリングし、メモリー使用量、アプリケーションのユースケース、およびアプリケーション環境における変化に基づき、複数のメモリー傾向を生成する系統的なアプローチを提供する。例えば、開示のシステムは、アプリケーションのメモリーの定期的なモニタリング、および実行中のメモリー（live memory）内のメモリーからの複数の入力を収集することを目的し、それにより、複数の大規模なダンプファイル（dump files）を処理することを回避することができる。本システムは、複数の被疑メモリー割り当ての位置を探し出すことを目的とするだけでなく、アプリケーションのユースケースを参照して、複数の被疑メモリー割り当ての位置を関連付けることも目的としている。また、本システムは、メモリー使用量、ガベージ収集、および関連アプリケーションユースケースに基づいて、メモリーの複数の傾向を生成するよう構成されている。

実施形態の１つにおいて、システムは、複数のメモリー被疑部のためにアプリケーションをモニタリングし、さらに、様々なユースケース実行において観測された複数のメモリー傾向に基づいて、影響を受けるユースケースまたはビジネス処理をモニタリングするよう構成されている。アプリケーションは、様々なユースケースが系統的に実行される制御された環境においてモニタリングされ、さらに、ユーザー始動または自動設定によって、メトリクスがスナップショットとして取得される。スナップショットは、ユースケース毎にカテゴリー分けされ、さらに、ユースケースまたはビジネス処理を特定するための関連アプリケーションコンテキストを含んでいる。複数の傾向から特定された複数の被疑部が解消された後、システムは、さらに、複数の以前のスナップショットを比較および検証することを容易とする。開示される本発明のシステムおよび方法においては、ヒープダンプ（heap dump）の全てが解析される代わりに、メモリースナップショットのみが解析される。メモリースナップショットのサイズは、ヒープダンプと比較して非常に小さく、そのため、容易に解析することができる。さらに、システムは、アプリケーションコンテンキストと共にコードレベルにおけるオブジェクトの根本原因を特定することを容易とする。ここで、オブジェクトの根本原因の特定は、影響を受けるユースケースまたはビジネス処理を発見することも含む。そのため、システムは、複数のメモリーエラーの根本原因の特定において有用である。

しかしながら、本発明による保護範囲は、メッセージを有する非一時的コンピューター可読手段に加え、プログラムにも及ぶことは理解されるであろう。そのようなコンピューター可読記憶媒体は、サーバー、携帯デバイス、または任意の適切なプログラム可能デバイス上でプログラムが実行されたとき、本発明の方法の１つ以上の工程を実施するプログラムコード手段（program-code means）を含む。ハードウェアデバイスは、例えば、サーバー、パーソナルコンピューター等、または、これらの組み合わせの任意の種類のコンピューターを含む任意の種類のプログラム可能なデバイスであってもよい。また、デバイスは、例えば、ハードウェア手段（例えば、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））、ハードウェア手段およびソフトウェア手段の組み合わせ（例えば、ＡＳＩＣおよびＦＰＧＡ）、少なくとも１つのマイクロプロセッサー、および、ソフトウェアモジュールが内部に保存されている少なくとも１つのメモリーのような手段を含む。よって、手段は、ハードウェア手段と、ソフトウェア手段の双方を含む。本発明の方法は、ハードウェアおよびソフトウェアにおいて実施可能である。また、デバイスは、ソフトウェア手段を含んでいてもよい。代替的に、本発明は、複数の異なるハードウェアデバイス、例えば、複数のＣＰＵを用いて、実施されていてもよい。

本発明は、ハードウェア要素と、ソフトウェア要素とを含むことができる。本発明は、ソフトウェアにおいて実施することができ、これに限定されるものではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含む。ここに説明された様々なモジュールによって実行される機能は、他のモジュールや他のモジュールの組み合わせにおいて実施されてもよい。説明の目的のため、コンピューター使用可能またはコンピューター可読媒体は、命令実行システム、装置、またはデバイスによって使用可能またはこれらに関連するプログラムを含み、保存し、通信し、伝播し、または伝送可能な任意の装置であってもよい。

特定の実施および実施形態の上述の記載は、本発明の実施および実施形態の一般的性質を十分に明らかにしており、現在の知識、容易な変形、および／または様々なアプリケーションへの適応を、本発明の全体的な考え方から逸脱することなく、特定の実施形態に適用することができる。さらに、そのため、そのような適応および変形は、開示の実施形態と同等な意味および範囲内に包含されるものである。本発明において使用された表現や専門用語は、説明の目的のために使用されたものであって、限定を構成するものではないことは理解されるであろう。そのため、本発明の実施形態は、好ましい実施形態に関連して説明されたが、本分野における当業者であれば、本発明の実施形態は、説明された本発明の考え方および範囲内における変形を行い実施可能であることは理解できるであろう。

上記の記述が、様々な実施形態を参照して提供された。本発明の属する分野および技術における当業者であれば、記述された構造および動作方法における変形および変更が、本発明の原理、考え方、および範囲から有意に逸脱することなく、実行可能であることを理解できるであろう。

異なるファームウェアおよび／またはソフトウェア実施において、関数は、１つ以上の命令またはコードとして、非一時的コンピューター可読媒体に保存されていてもよい。コンピューター可読媒体の例としては、データ構造でエンコードされたコンピューター可読媒体、およびコンピュータープログラムでエンコードされたコンピューター可読媒体を挙げることができる。コンピューター可読媒体は、製造者の製品の形態をとることができる。コンピューター可読媒体は、物理コンピューター保存媒体を含んでいる。保存媒体は、コンピューターによってアクセスされることができる任意の利用可能な媒体である。このようなコンピューター可読媒体の例としては、これに限定されるものではないが、コンピューターによってアクセスされることができ、さらに、命令やデータの形式の所望のプログラムコードを保存するために利用可能なＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、その他光ディスク保存デバイス、磁気ディスク保存デバイス、その他磁気保存デバイス、その他媒体等が挙げられる。ここで用いられるディスクは、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク、ブルーレイディスク等の通常は磁気的に、またはレーザーを用いて光学的にデータを再生するディスクを含む。また、上述のものの組み合わせも、コンピューター可読媒体の範囲内に含まれる。

Claims (13)

1. メモリー被疑部検出のためのコンピューター実施方法であって、
   アプリケーションの複数のクラスおよび複数のバイナリーデータを変換することにより、複数の被疑メモリー割り当てに関連する前記アプリケーションの複数の処理を系統的に実行し、メトリクスを生成する工程であって、前記アプリケーションの前記複数のクラスおよび前記複数のバイナリーデータは、少なくとも１つの所定の基準を満たしている、前記メトリクスを生成する工程と、
   前記複数の処理を系統的に実行している間に生成された前記メトリクスを定期的に取得する工程であって、前記複数の処理のうちの１つの処理の実行において生成された前記メトリクスは、少なくとも前記複数の処理のうちの前記１つの処理に関連するメモリー割り当て情報を含み、さらに、前記メモリー割り当て情報は、メモリー割り当てタイプ、タイムスタンプ、サイズ、および割り当ての発端を含む、前記メトリクスを定期的に取得する工程と、
   前記生成されたメトリクスに基づいて前記アプリケーション内のバイナリー実行論理を実行し、前記アプリケーションから実行時環境への１つ以上のメモリー割り当て要求を追跡する工程と、
   前記複数の処理のそれぞれの前記定期的に取得されたメトリクスに対する解析を実行することにより、複数のメモリー割り当てのそれぞれのタイプおよびクラスのサイズとカウントにおける変化を判別する工程と、
   前記複数のメモリー割り当てのそれぞれの前記タイプおよび前記クラスの前記サイズと前記カウントにおける前記変化に基づいて、前記複数の被疑メモリー割り当てによる影響を受ける前記複数の処理の中から、複数の処理のセットを特定する工程と、
   前記複数のメモリー割り当てのクラスを変換し、前記複数の被疑メモリー割り当てのメモリープロファイリングに必要な関連データを収集する工程と、
   前記複数の被疑メモリー割り当ての位置を探し出し、メモリー使用量、ガベージ収集、および関連アプリケーションユースケースに基づいて、メモリーの１つ以上の傾向を生成する工程と、を含み、
   前記複数の被疑メモリー割り当ては、共有メモリー問題として識別されているクラス、複数の以前の実行に起因するメモリー問題に関連するクラス、およびユーザー関心に関連するクラスの１つ以上に関連していることを特徴とするコンピューター実施方法。
2. 前記複数の処理を系統的に実行する工程は、メモリーモニタリングセッションの間、前記複数の処理のうちの少なくとも１つの処理を、実行時環境において複数回反復して実行する工程を含み、
   前記少なくとも１つの処理を反復して実行する工程は、前記少なくとも１つの処理に対応する前記１つ以上のメモリー割り当て要求を生成する工程を含む請求項１に記載のコンピューター実施方法。
3. 前記メモリーモニタリングセッションの間の前記少なくとも１つの処理の反復実行に関連する前記メトリクスを定期的に取得する工程は、少なくとも前記メモリーモニタリングセッションの開始時および終了時、並びに、前記メモリーモニタリングセッション中に少なくとも１回、前記メトリクスを取得する工程を含む請求項２に記載のコンピューター実施方法。
4. 前記１つ以上のメモリー割り当て要求のそれぞれを、対応するユニーク識別子でタグ付けする工程をさらに含み、
   前記１つ以上のメモリー割り当て要求のうちの１つのメモリー割り当て要求に関連するユニーク識別子は、対応する割り当てられたメモリー位置のハッシュコードと、前記１つのメモリー割り当て要求に応答して作成されたオブジェクトのタイプと、前記オブジェクトの作成時のタイムスタンプと、メモリー割り当て要求の発端となったソースコードの位置とを含む請求項２に記載のコンピューター実施方法。
5. 前記メトリクスは、アプリケーションメモリー情報をさらに含み、
   前記アプリケーションメモリー情報は、前記アプリケーションによって利用されるメモリーに関連付けられた１つ以上の情報と、メモリーをクリーンアップするために実行時環境によって為される試行の数と、前記メモリーをクリーンアップするために費やされる時間と、前記メトリクスの取得時のタイムスタンプとを含む請求項１に記載のコンピューター実施方法。
6. 前記複数の被疑メモリー割り当てによって影響を受ける前記複数の処理のセットを特定する工程は、
   前記複数の処理の実行において生成された前記メトリクスを追加する工程と、
   前記少なくとも１つの処理の反復実行の間に生成され、定期的に取得された前記メトリクスの比較に基づいて、前記複数の被疑メモリー割り当てに関連する複数のメモリー傾向を特定する工程と、を含み、
   前記メトリクスを追加する工程は、前記複数の処理の対応する処理毎に前記メトリクスを対応付ける工程を含む請求項１に記載のコンピューター実施方法。
7. メモリー被疑部検出のためのコンピューター実施システム（２００）であって、
   少なくとも１つのメモリー（２０４）と、
   前記少なくとも１つのメモリー（２０４）に接続された少なくとも１つのプロセッサー（２０２）と、を含み、
   前記少なくとも１つのプロセッサー（２０２）は、前記少なくとも１つのメモリー内に保存されている複数のプログラム命令を実行することにより、
   アプリケーションの複数のクラスおよび複数のバイナリーデータを変換することにより、複数の被疑メモリー割り当てに関連する前記アプリケーションの複数の処理を系統的に実行し、メトリクスを生成する工程であって、前記アプリケーションの前記複数のクラスおよび前記複数のバイナリーデータは、少なくとも１つの所定の基準を満たしている、前記メトリクスを生成する工程と、
   前記複数の処理を系統的に実行している間に生成された前記メトリクスを定期的に取得する工程であって、前記複数の処理のうちの１つの処理の実行において生成された前記メトリクスは、少なくとも前記複数の処理のうちの前記１つの処理に関連するメモリー割り当て情報を含む、前記メトリクスを定期的に取得する工程と、
   前記生成されたメトリクスに基づいて前記アプリケーション内のバイナリー実行論理を実行し、前記アプリケーションから実行時環境への１つ以上のメモリー割り当て要求を追跡する工程と、
   前記複数の処理のそれぞれの前記定期的に取得されたメトリクスに対する解析を実行することにより、複数のメモリー割り当てのそれぞれのタイプおよびクラスのサイズとカウントにおける変化を判別する工程と、
   前記複数のメモリー割り当てのそれぞれの前記タイプおよび前記クラスの前記サイズと前記カウントにおける変化に基づいて、前記複数の被疑メモリー割り当てによる影響を受ける前記複数の処理の中から、複数の処理のセットを特定する工程と、
   前記複数のメモリー割り当てのクラスを変換し、前記複数の被疑メモリー割り当てのメモリープロファイリングに必要な関連データを収集する工程と、
   前記複数の被疑メモリー割り当ての位置を探し出し、メモリー使用量、ガベージ収集、および関連アプリケーションユースケースに基づいて、メモリーの１つ以上の傾向を生成する工程と、を実行可能であり、
   前記複数の被疑メモリー割り当ては、共有メモリー問題として識別されているクラス、複数の以前の実行に起因するメモリー問題に関連するクラス、およびユーザー関心に関連するクラスの１つ以上に関連していることを特徴とするコンピューター実施システム。
8. 前記複数の処理を系統的に実行するために、前記少なくとも１つのプロセッサー（２０２）は、前記複数のプログラム命令を実行することにより、メモリーモニタリングセッションの間、前記複数の処理のうちの少なくとも１つの処理を、実行時環境において複数回反復して実行する工程をさらに実行可能であり、
   前記少なくとも１つの処理を反復して実行するために、前記少なくとも１つのプロセッサーは、前記複数のプログラム命令を実行することにより、前記少なくとも１つの処理に対応する前記１つ以上のメモリー割り当て要求を生成する工程をさらに実行可能である請求項７に記載のコンピューター実施システム。
9. 前記メモリーモニタリングセッションの間の前記少なくとも１つの処理の反復実行に関連する前記メトリクスを定期的に取得するために、前記少なくとも１つのプロセッサー（２０２）は、前記複数のプログラム命令を実行することにより、少なくとも前記メモリーモニタリングセッションの開始時および終了時、並びに、前記メモリーモニタリングセッション中に少なくとも１回、前記メトリクスを取得する工程をさらに実行可能な請求項８に記載のコンピューター実施システム。
10. 前記少なくとも１つのプロセッサー（２０２）は、前記複数のプログラム命令を実行することにより、
    前記１つ以上のメモリー割り当て要求のそれぞれを、対応するユニーク識別子でタグ付けする工程と、
    前記複数の処理のそれぞれに対応する前記メトリクスを、前記対応するユニーク識別子に関連付ける工程と、をさらに実行可能であり、
    前記１つ以上のメモリー割り当て要求のうちの１つのメモリー割り当て要求に関連するユニーク識別子は、対応する割り当てられたメモリー位置のハッシュコードと、前記１つのメモリー割り当て要求に応答して作成されたオブジェクトのタイプと、前記オブジェクトの作成時のタイムスタンプと、ソースおよび実行時における前記オブジェクトの位置とを含む請求項８に記載のコンピューター実施システム。
11. 前記メトリクスは、アプリケーションメモリー情報をさらに含み、
    前記アプリケーションメモリー情報は、前記アプリケーションによって利用される１つ以上のメモリーと、メモリーをクリーンアップするために実行時環境によって為される試行の数と、前記メモリーをクリーンアップするために費やされる時間と、前記メトリクスの取得時のタイムスタンプとを含む請求項７に記載のコンピューター実施システム。
12. 前記メトリクスに関連する前記メモリー割り当て情報は、メモリー割り当てタイプ、タイムスタンプ、サイズ、および割り当ての発端をさらに含む請求項７に記載のコンピューター実施システム。
13. 前記複数の被疑メモリー割り当てによって影響を受ける前記複数の処理のセットを特定するために、前記少なくとも１つのプロセッサーは、前記複数のプログラム命令を実行することにより、
    前記複数の処理の実行において生成された前記メトリクスを追加する工程と、
    前記少なくとも１つの処理の反復実行の間に生成され、定期的に取得された前記メトリクスの比較に基づいて、前記複数の被疑メモリー割り当てに関連する複数のメモリー傾向を特定する工程と、をさらに実行可能であり、
    前記メトリクスを追加する工程は、前記複数の処理の対応する処理毎に前記メトリクスを対応付ける工程を含む請求項１２に記載のコンピューター実施システム。

Images