JP2016134057A - 情報処理装置、制御方法及びプログラム - Google Patents
情報処理装置、制御方法及びプログラム Download PDFInfo
- Publication number
- JP2016134057A JP2016134057A JP2015009195A JP2015009195A JP2016134057A JP 2016134057 A JP2016134057 A JP 2016134057A JP 2015009195 A JP2015009195 A JP 2015009195A JP 2015009195 A JP2015009195 A JP 2015009195A JP 2016134057 A JP2016134057 A JP 2016134057A
- Authority
- JP
- Japan
- Prior art keywords
- application
- information
- objects
- acquired
- heap area
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Memory System (AREA)
Abstract
【課題】アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出すること。【解決手段】本発明にかかる情報処理装置は、アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、所定の契機により、所定のアプリケーションの識別情報に対応付けられたオブジェクト特定情報のリストをロードオブジェクト管理情報から取得する第1の取得手段と、リストに含まれる各オブジェクト特定情報により特定される各オブジェクトをヒープ領域から取得する第2の取得手段と、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第3の取得手段と、取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、を備える。【選択図】図1
Description
本発明は、情報処理装置、制御方法及びプログラムに関し、特に、アプリケーションのメモリ使用量を算出するための情報処理装置、制御方法及びプログラムに関する。
Java(登録商標)プログラムを実行するJVM(Java Virtual Machine)は、Javaプログラムが使用するヒープメモリ領域のサイズを、起動時に指定することができる。ヒープメモリ領域のサイズは適切な量を設定することが望ましい。ヒープメモリ領域が少な過ぎる場合には、Javaプログラム実行時にメモリが枯渇してガベージコレクションが頻発し、アプリケーションのパフォーマンスが低下してしまう。また、ヒープメモリ領域が多過ぎる場合には、ガベージコレクション実行時にガベージコレクションの処理対象となるオブジェクトが多くなるためにJavaアプリケーションが長時間停止するためである。このことはWebアプリケーションを実行するアプリケーションサーバでも同様である。
ところで、アプリケーションサーバは、1つのJVM上でアプリケーションサーバ自身とアプリケーションサーバに配備した0個以上のアプリケーションが動作する。このため、アプリケーションサーバが動作するJavaプロセスの適切なヒープメモリサイズを算出するためには、各配備アプリケーションが使用するヒープメモリサイズを知る必要がある。
また、アプリケーションサーバに複数個アプリケーションを配備する環境において、配備アプリケーションがメモリリークを起こした場合、複数のアプリケーションがメモリ空間を共有するため、どのアプリケーションがメモリリークを起こしているのかを特定するのが困難である。
ここで、特許文献1には、メモリ不足エラーやJavaアプリケーションの追加または削除など、ヒープ領域のサイズの変更要因を検出した場合に、ヒープ領域のサイズを変更する技術が開示されている。
しかしながら、特許文献1にかかる技術は、アプリケーション単位のヒープ領域サイズの精度が不十分であるという問題点がある。その理由は、特許文献1にかかる技術では、アプリケーション単位のヒープ領域サイズが、アプリケーション定義ファイルとして予め定義された値であるため、当該アプリケーションの実行時に実際に使用されているヒープ領域を測定したものではないためである。
本発明は、このような問題点を解決するためになされたものであり、アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出するための情報処理装置、制御方法及びプログラムを提供することを目的とする。
本発明の第1の態様にかかる情報処理装置は、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する第1の取得手段と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する第2の取得手段と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第3の取得手段と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、
を備える。
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する第1の取得手段と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する第2の取得手段と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第3の取得手段と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、
を備える。
本発明の第2の態様にかかる情報処理装置の制御方法は、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録し、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得し、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得し、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得し、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する。
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録し、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得し、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得し、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得し、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する。
本発明の第3の態様にかかるプログラムは、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する処理と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する処理と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する処理と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する処理と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する処理と、
をコンピュータに実行させる。
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する処理と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する処理と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する処理と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する処理と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する処理と、
をコンピュータに実行させる。
本発明により、アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出するための情報処理装置、制御方法及びプログラムを提供することができる。
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
(実施形態1)
図1は、本発明の実施の形態1にかかる情報処理装置1の構成を示すブロック図である。情報処理装置1は、ヒープ領域10と、ロードオブジェクト管理情報20と、登録手段30と、第1の取得手段40と、第2の取得手段50と、第3の取得手段60と、算出手段70とを備える。
図1は、本発明の実施の形態1にかかる情報処理装置1の構成を示すブロック図である。情報処理装置1は、ヒープ領域10と、ロードオブジェクト管理情報20と、登録手段30と、第1の取得手段40と、第2の取得手段50と、第3の取得手段60と、算出手段70とを備える。
ヒープ領域10は、情報処理装置1が有する記憶装置(不図示)内のメモリ領域のうち、アプリケーションを実行するために割り当てられる領域(ヒープメモリ)である。ロードオブジェクト管理情報20は、ヒープ領域10にロードされたオブジェクト11を管理するための情報である。ロードオブジェクト管理情報20は、アプリケーション識別情報21と、オブジェクト特定情報22とを対応付けて保持する。オブジェクト特定情報22は、オブジェクト11を特定する情報である。オブジェクト特定情報22は、オブジェクト11のロードデータ自体ではなく、オブジェクト11を参照するための情報である。例えば、オブジェクト特定情報22は、弱参照オブジェクトであることが望ましいが、これに限定されない。尚、ロードオブジェクト管理情報20は、ヒープ領域10と同一又は異なる記憶装置内に存在するものである。
登録手段30は、アプリケーションの実行に応じてヒープ領域10にオブジェクト11が生成された際に、オブジェクト11を特定するオブジェクト特定情報22を、当該アプリケーションのアプリケーション識別情報21と対応付けてロードオブジェクト管理情報に登録する。第1の取得手段40は、所定の契機により、所定のアプリケーション識別情報21に対応付けられたオブジェクト特定情報22のリストをロードオブジェクト管理情報20から取得する。第2の取得手段50は、前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトをヒープ領域10から取得する。第3の取得手段60は、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する。すなわち、ここでは、所定のアプリケーション自体に直接実装されていないオブジェクトであっても、参照先のオブジェクトの全てが取得される。算出手段70は、取得された全てのオブジェクトのメモリ使用量の合計値を算出する。
図2は、本発明の実施の形態1にかかるメモリ使用量算出処理の流れを示すフローチャートである。まず、登録手段30は、アプリケーションの実行に応じてヒープ領域10にオブジェクト11が生成された際に、オブジェクト11を特定するオブジェクト特定情報22を、当該アプリケーションの識別情報21と対応付けてロードオブジェクト管理情報20に登録する(S11)。
次に、第1の取得手段40は、所定の契機により、所定のアプリケーションの識別情報21に対応付けられたオブジェクト特定情報22のリストをロードオブジェクト管理情報20から取得する(S12)。続いて、第2の取得手段50は、前記リストに含まれる各オブジェクト特定情報22により特定される各オブジェクトをヒープ領域10から取得する(S13)。そして、第3の取得手段60は、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する(S14)。その後、算出手段70は、取得された全てのオブジェクトのメモリ使用量の合計値を算出する(S15)。
このように、本発明の実施の形態では、当該アプリケーション内に実装された各クラスのうち、ヒープ領域に実際に生成されたオブジェクトについて、当該オブジェクトを特定する情報を保持しておくものである。そして、メモリ使用量の算出時(所定の契機)においても実際にヒープ領域に存在するオブジェクトを対象とすることができる。そして、当該オブジェクトから参照されるオブジェクトを全て取得することで、当該アプリケーションの動作のために実際に必要とされるオブジェクトを網羅するものである。そして、網羅された各オブジェクトの使用メモリサイズを元に、実際に確保されているヒープ領域を正確に算出することができる。
(実施形態2)
本実施の形態2は、上述した実施の形態1の具体例である。ここで、本実施の形態が解決しようとする課題を詳述する。
本実施の形態2は、上述した実施の形態1の具体例である。ここで、本実施の形態が解決しようとする課題を詳述する。
例えば、Java EEアプリケーションサーバではWebアプリケーションやEJBアプリケーションを複数個配備することができる。このとき、アプリケーションサーバとアプリケーションサーバに配備したアプリケーションは、1つのJava VMプロセス上で動作し、アプリケーションサーバと配備アプリケーションは、Java VMのヒープメモリ空間を共有する。このため、ある配備アプリケーションがメモリリーク等を原因にヒープメモリを大量に確保してヒープメモリが枯渇すると、その影響を他の配備アプリケーションやアプリケーションサーバも受ける。
尚、Javaにおける実行時のヒープメモリ使用量はhprofに代表されるメモリダンプツールを用いることで測定が可能である。しかしながら、当該メモリダンプツールは、javaプロセス全体のヒープメモリ使用量であり、アプリケーションサーバ上で動作する各配備アプリケーションのヒープメモリ使用量を知ることは出来ない。また、メモリリークが疑われないアプリケーションサーバ自身のヒープメモリの情報も取得するため、メモリの取得にかかる時間が長くなるという問題がある。
そこで、本実施の形態では以下の構成により上述した課題を解決するものである。
図3は、本発明の実施の形態2にかかる情報処理装置200のハードウェア構成を示すブロック図である。情報処理装置200は、メモリ300、CPU400及びハードディスク500を備えるコンピュータ装置である。尚、情報処理装置200は、汎用的なコンピュータ装置が備える他の構成を有しており、以下では図示及び説明を省略する。
メモリ300は、揮発性記憶装置である。メモリ300は、ヒープメモリ310、ルートオブジェクト参照表320及びオブジェクト一時記憶部330を含む。ヒープメモリ310は、上述したヒープ領域10の一例である。ヒープ領域10は、JVM520上で動作するプログラムが生成するオブジェクト311、312を記憶するメモリ領域である。ルートオブジェクト参照表320は、上述したロードオブジェクト管理情報20の一例である。ルートオブジェクト参照表320は、キーをクラスローダ情報321、値を弱参照オブジェクト322とするマップのデータ構造である。クラスローダ情報321は、複数のアプリケーション540のそれぞれを識別するアプリケーション識別情報21の一例である。弱参照オブジェクト322は、上述したオブジェクト特定情報22の一例である。ここで、弱参照とは、参照先のオブジェクトをガベージコレクタ522による解放から守ることのできない参照である。
オブジェクト一時記憶部330は、算出対象オブジェクト331を記憶する記憶領域である。算出対象オブジェクト331は、参照オブジェクト取得部523によりオブジェクト一時記憶部330に格納される。また、オブジェクト一時記憶部330は、メモリ使用量計算部524がメモリ使用量を計算する際に用いられる。そのため、オブジェクト一時記憶部330は、参照オブジェクト取得部523及びメモリ使用量計算部524からアクセスされる。
尚、メモリ300には、上記の他にOS510やJVM520の実行領域が通常通り確保されるものとする。
ハードディスク500は、OS(Operating System)510、JVM520、アプリケーションサーバ530、アプリケーション540を記憶する不揮発性記憶装置である。OS510は、公知のものと同様であるため説明を省略する。JVM520は、Javaプログラムを実行するアプリケーション実行装置の一例である。特に、本実施の形態にかかるJVM520は、オブジェクト生成部521、ガベージコレクタ522、参照オブジェクト取得部523及びメモリ使用量計算部524を備える。尚、JVM520は、これらの構成の他、図示しない一般的な構成を含むものとする。
オブジェクト生成部521は、JVM520上でのオブジェクトの生成処理を行う。ガベージコレクタ522は、ヒープメモリ310に存在するオブジェクトの使用状況を確認し、使用されなくなったオブジェクトをヒープメモリ310から解放し、そのメモリ領域を他のオブジェクトに割り当て可能にする。
参照オブジェクト取得部523は、任意のオブジェクトから参照されるオブジェクトを再帰的に取得し、オブジェクト一時記憶部330に算出対象オブジェクト331として格納する。メモリ使用量計算部524は、アプリケーションサーバ530に配備された任意のアプリケーション540のヒープメモリ使用量を計算する。
アプリケーションサーバ530は、複数のアプリケーション540の実行を管理するサーバソフトウェアである。アプリケーションサーバ530は、配備部531を備える。配備部531は、アプリケーションサーバ530の管理者によるアプリケーション配備要求を受け付けて、要求されたアプリケーション540をアプリケーションサーバ530に配備し、アプリケーション540を実行可能な状態にする。また、配備部531は、アプリケーションサーバ530の管理者によるアプリケーション配備解除要求を受け付けて、要求されたアプリケーション540を停止し、アプリケーションサーバ530から削除する。
アプリケーション540は、1以上のJavaのクラス542が実装されたJavaアプリケーションである。また、アプリケーション540は、配備部531に生成されたクラスローダ541を含むということができる。
情報処理装置200は、CPU400が、ハードディスク500からOS510、JVM520、アプリケーションサーバ530及びアプリケーション540を読み出し、メモリ300上に展開して実行することで、本発明の実施の形態を実現する。
図4は、本発明の実施の形態2にかかるJVM、アプリケーションサーバ、配備アプリケーションの関係を説明するための概要図である。上述した図3は、本実施の形態のハードウェア構成を図示したものであり、図4は図3で示した各構成について、制御の関係を中心に示した概念図といえる。
JVM100は、本実施の形態の一実現例である。JVM100は、図3のOS510及びJVM520がCPU400により情報処理装置200上で実行された状態を示す。JVM100は、オブジェクト生成部104、ガベージコレクタ106、参照オブジェクト取得部103及びメモリ使用量計算部101として動作し、オブジェクト一時記憶部102、ヒープメモリ105及びアプリケーションサーバ110を制御する。尚、これらの構成は、それぞれ図3のオブジェクト生成部521、ガベージコレクタ522、参照オブジェクト取得部523、メモリ使用量計算部524、ヒープメモリ310、オブジェクト一時記憶部330及びアプリケーションサーバ530に対応する。
また、アプリケーションサーバ110は、配備部111、ルートオブジェクト参照表112、アプリケーション120a〜120cを制御する。尚、これらの構成は、それぞれ図3の配備部531、ルートオブジェクト参照表320、アプリケーション540に対応する。
アプリケーションサーバ110は、起動時に配備済みのアプリケーションのアプリケーションクラスローダを取得し、ルートオブジェクト参照表112にアプリケーションクラスローダ113として登録する。アプリケーションサーバ110は、1以上のアプリケーションが動作する。
配備部111は、アプリケーションサーバ110の起動後に、未配備のアプリケーション120a〜120cをアプリケーションサーバ110に配備する際に、アプリケーションごとにユニークなアプリケーションクラスローダ121a〜121cを生成する。その後、配備部111は、ルートオブジェクト参照表112に新規エントリーを作成し、生成したアプリケーションクラスローダをルートオブジェクト参照表112のアプリケーションクラスローダ113として登録する。
ここで、一般に、アプリケーションサーバ110は、配備する異なるアプリケーションでの同じ名前のクラスが競合することを避けるため、アプリケーションごとに異なるクラスローダを用いてアプリケーションのクラスをロードしている。
また、配備部111は、配備解除を要求されたアプリケーション(例えば、アプリケーション120a)を停止し、アプリケーションサーバ110上から停止したアプリケーション120aを削除する。この時、配備部111は、アプリケーション120aのアプリケーションクラスローダ121aをアプリケーションクラスローダ113に持つエントリーをルートオブジェクト参照表112から削除する。
アプリケーション120a〜120cは、アプリケーションサーバ110に配備されたアプリケーションである。アプリケーション120a〜120cは、自己に定義されたクラスを、配備部111が生成したアプリケーションクラスローダ121a〜121cによりオブジェクトを生成させる。つまり、アプリケーションクラスローダ121a〜121cは、ヒープメモリ105に対してクラスのロードを実行する。アプリケーションクラスローダ121a〜121cは、ロードの実行時に、オブジェクト生成部104を呼び出す。
オブジェクト生成部104は、アプリケーションサーバ110やアプリケーション120a〜120cに実装されたクラスからオブジェクトを生成する際にクラスローダから呼び出され、生成したオブジェクトをヒープメモリ105に格納する。併せて、本実施の形態にかかるオブジェクト生成部104は、上述した登録手段30としても機能する。具体的には、オブジェクト生成部104は、生成したオブジェクトの実装クラスのクラスローダを調べる。そして、当該クラスローダがアプリケーションサーバ110上のアプリケーション120a〜120cのものである場合、オブジェクト生成部104は、生成したオブジェクトへの弱参照オブジェクトを作成し、ルートオブジェクト参照表112内の該当するアプリケーションクラスローダ113に対応付けて弱参照リスト114に弱参照オブジェクトを格納する。
ガベージコレクタ106は、例えば、ヒープメモリ105上のオブジェクトAが他のどのオブジェクトからも参照されていない場合に、オブジェクトAが使用されなくなったと判断する。また、ガベージコレクタ106は、オブジェクトAへの全ての参照の強さが弱参照以下である場合も、オブジェクトAを使用されなくなったと判断する。
オブジェクト一時記憶部102は、ヒープメモリ105内のオブジェクトのうち、メモリ使用量の算出対象であるアプリケーションの実行に応じて生成されたオブジェクトの情報を展開する領域である。このため、ヒープメモリ105の確保サイズを大きく設定してヒープメモリ105内にオブジェクトが大量に確保されれば、オブジェクト一時記憶部102が使用するデータサイズも大きくなる。これにより、オブジェクト一時記憶部102がシステムやJVM100の動作に悪影響を与えることを防ぐために、オブジェクト一時記憶部102は図4のようにJVM100内に確保せずに、例えば他のプロセス内部や補助記憶領域などのJVM100の外部に確保してもよい。
メモリ使用量計算部101は、オブジェクト一時記憶部102に格納されたオブジェクトのサイズの総和をメモリ使用量の合計値とする。または、メモリ使用量計算部101は、複数のアプリケーションの間でオブジェクトが重複する場合、当該重複分のメモリ使用量を総和から削除する。
図5は、本発明の実施の形態2にかかるアプリケーションサーバの起動時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ110は、管理者等の要求に応じて、JVM100上で起動する(S21)。次に、アプリケーションサーバ110は、配備済みのアプリケーション(例えば、アプリケーション120a)を起動し、アプリケーション120aのアプリケーションクラスローダ121aをルートオブジェクト参照表112に追加する(S22)。
これにより、ルートオブジェクト参照表112内に、配備アプリケーションのオブジェクト生成時における当該オブジェクトへの弱参照オブジェクトの登録先となるエントリーが生成される。この処理は、アプリケーションサーバ110に配備されたアプリケーションのうち、ヒープメモリの測定対象となり得る全てアプリケーションに対して行う。
図6は、本発明の実施の形態2にかかるオブジェクト生成時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ110又はアプリケーション120a〜120cの実行中に、定義されたクラスのオブジェクトの生成が必要になった際に、アプリケーションクラスローダからオブジェクト生成部104が呼び出される。そして、オブジェクト生成部104は、該当のクラスからオブジェクトを生成する(S31)。
次に、オブジェクト生成部104は、生成したオブジェクトのクラスローダを取得する(S32)。そして、オブジェクト生成部104は、取得したクラスローダがルートオブジェクト参照表112のアプリケーションクラスローダ113に存在するか否かを判定する(S33)。ここで、ルートオブジェクト参照表112のアプリケーションクラスローダ113には、ヒープメモリの取得対象となり得る全ての配備アプリケーション120a〜120cのアプリケーションクラスローダ121a〜121cが登録されている。また、配備アプリケーション120a〜120c以外のクラスローダは、アプリケーションクラスローダ113に存在しない。そのため、この判定により、生成されたオブジェクトがアプリケーション120a〜120cで定義されたクラスであるか否かが判別できる。
ステップS33においてクラスローダが存在すると判定した場合、オブジェクト生成部104は、生成するオブジェクトの弱参照オブジェクトを生成する。そして、オブジェクト生成部104は、生成した弱参照オブジェクトを、該当するアプリケーションクラスローダ113に対応する弱参照リスト114に追加する(S34)。これにより、後述するヒープメモリの測定時にアプリケーションごとに生成されたオブジェクトを弱参照リスト114から取得することができるようになる。一方、ステップS33においてクラスローダが存在しないと判定した場合、当該処理を終了する。
図7は、本発明の実施の形態2にかかるアプリケーション配備時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ110は、運用者(管理者)からアプリケーションの配備要求を受け付ける(S41)。ここで、配備要求には、配備対象のアプリケーションが指定されているものとする。
次に、配備部111は、指定されたアプリケーション(例えば、アプリケーション120a)に対応するアプリケーションクラスローダ121aを生成し、ルートオブジェクト参照表112のアプリケーションクラスローダ113に追加する(S42)。生成されるアプリケーションクラスローダ121aは、配備するアプリケーション120aに定義されたクラスを読み込むものである。
続いて、配備部111は、生成したアプリケーションクラスローダ121aを用いて配備アプリケーションをロードし、アプリケーション120aをアプリケーションサーバ110に配備する(S43)。
図8は、本発明の実施の形態2にかかるアプリケーション配備解除時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ110は、運用者(管理者)からアプリケーションの配備解除要求を受け付ける(S41)。ここで、配備解除要求には、配備解除対象のアプリケーションが指定されているものとする。
次に、配備部111は、配備解除を要求されたアプリケーション(例えば、アプリケーション120a)をアプリケーションサーバ110から配備解除する(S52)。そして、配備部111は、配備解除を要求されたアプリケーション120aのアプリケーションクラスローダ121aをアプリケーションクラスローダ113から削除する(S53)。すなわち、配備部111は、ステップS52で配備解除したアプリケーション120aのアプリケーションクラスローダ121aに対応するエントリーを、ルートオブジェクト参照表112から削除する。これにより、ルートオブジェクト参照表112とアプリケーション120aとにおいてクラスローダの整合性を取ることができる。
図9は、本発明の実施の形態2にかかる配備アプリケーションのヒープメモリ使用量を測定する処理の流れを説明するためのフローチャートである。ここで、当該ヒープメモリ使用量の測定処理は、運用者の要求、定期的なスケジュール、JVMのフルガーベージコレクションの発生などを契機に実行することが挙げられる。
まず、アプリケーションサーバ110は、ヒープメモリ使用量の測定対象であるアプリケーションのクラスローダを取得する(S61)。次に、アプリケーションサーバ110は、取得したクラスローダに対応する弱参照インスタンスの一覧をルートオブジェクト参照表112から取得する(S62)。
ここで、ルートオブジェクト参照表112は、上述した通り、アプリケーションクラスローダ113をキーに、弱参照リスト114を値に持つマップである。そして、キーと値は1対多の関係を持つ。そして、上述した図5〜図7の処理により弱参照リスト114は登録済みであり、一部は図8により削除済みである。このため、アプリケーションサーバ110は、クラスローダに対応する弱参照インスタンスの一覧をルートオブジェクト参照表112から取得することで、ヒープメモリ105内に存在する、対象アプリケーションで定義されたクラスのオブジェクトへの弱参照の一覧が取得できる。
図10は、本発明の実施の形態2にかかるルートオブジェクト参照表の例を示す図である。例えば、アプリケーション120aがヒープメモリ使用量の測定対象である場合、アプリケーションサーバ110は、ルートオブジェクト参照表112を参照し、アプリケーションクラスローダ121aに対応付けられている弱参照リスト114である、オブジェクト122a1、122a2、・・・のそれぞれへの弱参照オブジェクトを取得する。
図9に戻り説明を続ける。ここで、アプリケーションサーバ110は、弱参照インスタンスの一覧の各要素について、ステップS64からS68を繰返す(S63)。まず、アプリケーションサーバ110は、弱参照インスタンスが参照するオブジェクトをヒープメモリ105から取得する(S64)。
そして、アプリケーションサーバ110は、弱参照インスタンスが参照するオブジェクトの取得に成功したか否かを判定する(S65)。ここで上述した通り、弱参照とは、参照先のオブジェクトをガベージコレクタ106による解放から守ることのできない参照である。そのため、弱参照のみで参照されるオブジェクトは、ガベージコレクタ106によりいつでも解放することができる。従って、参照先のオブジェクトがどこからも参照されなくなった場合は、ガベージコレクタ106により解放されている可能性があり、ステップS65においてオブジェクトの取得に失敗する。
ステップS65において失敗と判定した場合、アプリケーションサーバ110は、ルートオブジェクト参照表112の弱参照リスト114から、この弱参照インスタンスを削除する(S66)。尚、この処理は、ステップS66のタイミングで実施する代わりに、ガベージコレクションが完了するごとに実施してもよい。その場合、デメリットとしてガベージコレクションを実施するたびに全ての弱参照オブジェクトの参照状況を確認する処理コストが発生する。しかしながら、参照を持たない弱参照オブジェクトが長期間ヒープメモリ領域にとどまり続けることを防ぐ事ができる。
ステップS65において成功と判定した場合、アプリケーションサーバ110は、取得したオブジェクトをオブジェクト一時記憶部102に格納する(S67)。尚、既にオブジェクト一時記録領域102に該当のオブジェクトが存在する場合には、アプリケーションサーバ110は格納を行わなくても良い。
続いて、参照オブジェクト取得部103は、オブジェクト一時記憶部102に格納されたオブジェクトから参照されるオブジェクトを全て再帰的に取得し、オブジェクト一時記憶領域102に格納する(S68)。このとき、オブジェクト一時記憶領域102に同じメモリアドレスにあるオブジェクトを複数登録することを避けるため、既にオブジェクト一時記憶領域102に該当のオブジェクトが記録されている場合、参照オブジェクト取得部103は記録をしない。また、参照オブジェクト取得部103は、そのオブジェクトが参照するオブジェクトについての参照オブジェクトの探索は行わない。そして、アプリケーションサーバ110及び参照オブジェクト取得部103は、弱参照インスタンスの一覧の各要素についてステップS64〜S68を繰り返し、全ての弱参照インスタンスについて処理が行われた場合、ステップS70へ進む(S69)。ステップS64〜S68の繰り返しにより、オブジェクト一時記録領域102には、対象のアプリケーションが参照する全てのオブジェクトが記録される。
その後、メモリ使用量計算部101は、オブジェクト一時記憶領域102に格納されたオブジェクトのヒープメモリ使用量の総和を計算する(S70)。尚、メモリ使用量計算部101は、オブジェクトの所有する各プリミティブ型の属性の数と参照(オブジェクト)型の属性の数、さらにそのオブジェクトの実装クラスの継承情報に基づいて、Javaオブジェクトのメモリ使用量を算出することができる。
図11は、本発明の実施の形態2にかかる配備アプリケーションが使用するオブジェクトの例を示す図である。例えば、配備アプリケーションであるアプリケーション120aに定義されたクラスから生成されたオブジェクトがオブジェクト122a1、122a2、及び122a3であった場合、アプリケーションaが使用するオブジェクト600が参照オブジェクト取得部103に格納されるオブジェクトとなる。
この場合、アプリケーションサーバ110は、弱参照リスト114としてオブジェクト122a1、122a2、及び122a3のそれぞれへの弱参照オブジェクトを取得する(S62)。そして、アプリケーションサーバ110は、ヒープメモリ105からオブジェクト122a1、122a2、及び122a3を取得する(S64)。その上で、アプリケーションサーバ110は、オブジェクト122a1、122a2、及び122a3をオブジェクト一時記憶部102に格納する(S67)。ここで、参照オブジェクト取得部103は、オブジェクト一時記憶部102に格納されたオブジェクト122a1、122a2、及び122a3のそれぞれについて、参照されるオブジェクトを再帰的に取得する(S68)。ここでは、アプリケーション120aには直接定義されていないオブジェクト611〜614、621〜623が取得され、オブジェクト一時記憶部102に格納される。尚、アプリケーション120bのオブジェクト122b1及びこれから参照されるオブジェクト631及び632については、測定対象外として除外される。
以上のことから本実施の形態により、あるアプリケーションが使用する全てのオブジェクトを、アプリケーションクラスローダが生成したオブジェクトから再帰的に参照を辿ってして取得するため、オブジェクトの取りこぼしがなく、アプリケーションのヒープメモリ使用量を正確に算出できる。また、アプリケーションサーバの平常時におけるヒープメモリ算出のための処理が少ないため、アプリケーションサーバへの負荷が少ない。さらに、ヒープメモリ使用量を算出するとき、算出対象の配備アプリケーションで使用するオブジェクトのみ走査し、それ以外の配備アプリケーションやアプリケーションサーバが使用するオブジェクトは算出対象の配備アプリケーションが参照を持たない限り走査しないため、ヒープダンプの出力より短時間でヒープメモリを取得できる。
また、アプリケーションサーバのように、一つのJava VMで複数のアプリケーションが動作している環境で、あるアプリケーションがメモリリーク等を原因にヒープメモリを大量に専有した場合に、他のアプリケーションが受ける影響を抑えることができる。
また、アプリケーションサーバのように、一つのJava VMで複数のアプリケーションが動作している環境で、あるアプリケーションがメモリリーク等を原因にヒープメモリを大量に専有した場合に、他のアプリケーションが受ける影響を抑えることができる。
尚、本実施の形態2は、実施の形態1に加えて、次のような構成を有するものである。すなわち、前記登録手段は、前記ヒープ領域に生成されたオブジェクトへの弱参照オブジェクトを前記オブジェクト特定情報として、当該アプリケーションと対応付けてロードオブジェクト管理情報に登録し、前記第2の取得手段は、前記リストに含まれる各弱参照オブジェクトの参照先である各オブジェクトを前記ヒープ領域から取得するものである。このように、オブジェクト特定情報として弱参照オブジェクトを用いることで、ガーベージコレクションによるオブジェクトの解放への影響を与えない。そのため、本実施の形態を適用することによる不要なメモリ容量確保を回避することができる。
さらに、前記第2の取得手段及び前記第3の取得手段により取得された各オブジェクトを、前記ヒープ領域以外の記憶領域に格納する格納手段をさらに備え、前記算出手段は、前記記憶領域に格納された各オブジェクトのメモリ使用量の総和を前記合計値として算出してもよい。これにより、メモリ使用量の合計値の算出処理を容易にすることができる。
さらにまた、前記第3の取得手段は、前記ヒープ領域のガーベージコレクションにおいてメモリを解放しないオブジェクトを特定する処理と併せて、前記参照される全てのオブジェクトを取得するようにしてもよい。言い換えると、メモリ使用量計算部101が行うアプリケーションから参照されるオブジェクトを取得する処理をガベージコレクタ106がフルガーベージコレクションを実行する際に実施する、参照オブジェクト(解放しないオブジェクト)をマーキングする処理に相乗りさせても良い。これらにより、ステップS64からS68の繰り返し処理の負荷を軽減することができる。
また、前記算出手段は、複数のアプリケーションについての前記メモリ使用量の合計値を算出する場合、当該複数のアプリケーション間で重複するオブジェクトについてのメモリ使用量の重複分を当該合計値から除くようにしてもよい。これにより、重複分が除かれ、メモリ使用量の精度がより向上する。
また、前記第2の取得手段において前記オブジェクト特定情報により前記ヒープ領域からオブジェクトが特定されない場合に、前記ロードオブジェクト管理情報から当該特定されないオブジェクトを削除する削除手段をさらに備えるようにしてもよい。これにより、管理情報がメンテナンスされ、整合性を保つことができる。
さらに、前記合計値と共に、前記第2の取得手段により取得された各オブジェクトを基点としたオブジェクトの参照関係を出力する出力手段をさらに備えるようにしてもよい。これにより、管理者等による最適なヒープ領域の検討を支援することができる。
また、前記第3の取得手段は、前記取得された各オブジェクトから参照されるオブジェクトを再帰的に取得する。これにより、参照オブジェクトを網羅することができる。
(その他の実施形態)
上述した実施形態2は次のような側面がある。まず、配備アプリケーションで定義するクラスのオブジェクトが生成された時に、そのオブジェクトへの弱参照をマップ上に保持し、弱参照を配備アプリケーションごとに管理するものである。そして、配備アプリケーションで定義するクラスのオブジェクトから、直接的あるいは間接的に参照されるオブジェクトの一覧を取得することで配備アプリケーションのヒープメモリ使用量を計算するものである。
上述した実施形態2は次のような側面がある。まず、配備アプリケーションで定義するクラスのオブジェクトが生成された時に、そのオブジェクトへの弱参照をマップ上に保持し、弱参照を配備アプリケーションごとに管理するものである。そして、配備アプリケーションで定義するクラスのオブジェクトから、直接的あるいは間接的に参照されるオブジェクトの一覧を取得することで配備アプリケーションのヒープメモリ使用量を計算するものである。
また、次のような側面もある。すなわち、実施形態2は、独自拡張したJVMを用いるものである。このJVMは、アプリケーションサーバ上の各アプリケーションで定義したクラスのオブジェクトが生成されたことを検出する機構と、この機構で検出した生成オブジェクトへの弱参照を保持する機構であるメモリ参照管理空間を持つ。そして、アプリケーションのヒープメモリサイズ取得時には、メモリ参照管理空間に保持する弱参照されたオブジェクトから直接的、あるいは間接的に到達可能なオブジェクトを全て取得する。取得した弱参照されたオブジェクトから到達可能なオブジェクトの一覧から重複を除いて、オブジェクトの総和を取ることでアプリケーションが使用するヒープメモリの総量を計算する。これにより、特定の配備アプリケーションにおけるヒープメモリサイズを取得できる。
また、アプリケーションサーバに複数のアプリケーションが配備された環境において、各配備アプリケーションが使用するヒープメモリサイズを正確に算出することで、運用者がアプリケーションサーバ全体の適切なヒープメモリを見積もることを支援できる。また、メモリリーク発生時に配備アプリケーションごとのメモリ使用量を算出することでリークを起こしている配備アプリケーションを迅速に特定することができる。
さらに、本発明の各実施の形態は、次のような変更が可能である。メモリ使用量計算部101のヒープメモリ使用量取得処理の前にガベージコレクションを行ない、予めJVM内で使用されないオブジェクトを解放しておいてもよい。
上記では独自に拡張したJVM100を用いて、オブジェクト生成処理にフックしてアプリケーション内のオブジェクトへの参照を取得していた。しかし、独自に拡張したJVMの代わりに、配備するアプリケーションのオブジェクト生成コード部分にフックイベントを呼び出すコードを埋め込んでも良いものとする。具体的な方法には、別途用意した開発環境で配備アプリケーションをビルドした場合にアプリケーションのソースコードの全ての具象クラスのコンストラクタにフックイベントを呼び出すコードを埋め込んでからコンパイルするなどが挙げられる。
上記図11では、ある配備アプリケーション(アプリケーションa)のオブジェクトが別の配備アプリケーション(アプリケーションb)のオブジェクトを参照する場合には、ヒープメモリ計算方法として配備アプリケーションbのオブジェクトを配備アプリケーションaのヒープメモリ使用量に含めずにヒープメモリ計算方法を述べた。但し、これを含めて計算しても良い。この場合、配備アプリケーションごとの動作に必要なヒープメモリの絶対量を測定することが出来る。
また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、CPU(Central Processing Unit)にコンピュータプログラムを実行させることにより実現することも可能である。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、DVD(Digital Versatile Disc)、BD(Blu-ray(登録商標) Disc)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
1 情報処理装置
10 ヒープ領域
11 オブジェクト
20 ロードオブジェクト管理情報
21 アプリケーション識別情報
22 オブジェクト特定情報
30 登録手段
40 第1の取得手段
50 第2の取得手段
60 第3の取得手段
70 算出手段
200 情報処理装置
300 メモリ
310 ヒープメモリ
311 オブジェクト
312 オブジェクト
320 ルートオブジェクト参照表
321 クラスローダ情報
322 弱参照オブジェクト
330 オブジェクト一時記憶部
331 算出対象オブジェクト
400 CPU
500 ハードディスク
510 OS
520 JVM
521 オブジェクト生成部
522 ガベージコレクタ
523 参照オブジェクト取得部
524 メモリ使用量計算部
530 アプリケーションサーバ
531 配備部
540 アプリケーション
541 クラスローダ
542 クラス
100 JVM
101 メモリ使用量計算部
102 オブジェクト一時記憶部
103 参照オブジェクト取得部
104 オブジェクト生成部
105 ヒープメモリ
106 ガベージコレクタ
110 アプリケーションサーバ
111 配備部
112 ルートオブジェクト参照表
113 アプリケーションクラスローダ
114 弱参照リスト
120a アプリケーション
121a アプリケーションクラスローダ
122a1 オブジェクト
122a2 オブジェクト
122a3 オブジェクト
120b アプリケーション
121b アプリケーションクラスローダ
122b1 オブジェクト
122b2 オブジェクト
120c アプリケーション
121c アプリケーションクラスローダ
600 アプリケーションaが使用するオブジェクト
611〜614、621〜623、631、632 オブジェクト
10 ヒープ領域
11 オブジェクト
20 ロードオブジェクト管理情報
21 アプリケーション識別情報
22 オブジェクト特定情報
30 登録手段
40 第1の取得手段
50 第2の取得手段
60 第3の取得手段
70 算出手段
200 情報処理装置
300 メモリ
310 ヒープメモリ
311 オブジェクト
312 オブジェクト
320 ルートオブジェクト参照表
321 クラスローダ情報
322 弱参照オブジェクト
330 オブジェクト一時記憶部
331 算出対象オブジェクト
400 CPU
500 ハードディスク
510 OS
520 JVM
521 オブジェクト生成部
522 ガベージコレクタ
523 参照オブジェクト取得部
524 メモリ使用量計算部
530 アプリケーションサーバ
531 配備部
540 アプリケーション
541 クラスローダ
542 クラス
100 JVM
101 メモリ使用量計算部
102 オブジェクト一時記憶部
103 参照オブジェクト取得部
104 オブジェクト生成部
105 ヒープメモリ
106 ガベージコレクタ
110 アプリケーションサーバ
111 配備部
112 ルートオブジェクト参照表
113 アプリケーションクラスローダ
114 弱参照リスト
120a アプリケーション
121a アプリケーションクラスローダ
122a1 オブジェクト
122a2 オブジェクト
122a3 オブジェクト
120b アプリケーション
121b アプリケーションクラスローダ
122b1 オブジェクト
122b2 オブジェクト
120c アプリケーション
121c アプリケーションクラスローダ
600 アプリケーションaが使用するオブジェクト
611〜614、621〜623、631、632 オブジェクト
Claims (10)
- アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する第1の取得手段と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する第2の取得手段と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第3の取得手段と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、
を備える情報処理装置。 - 前記登録手段は、
前記ヒープ領域に生成されたオブジェクトへの弱参照オブジェクトを前記オブジェクト特定情報として、当該アプリケーションと対応付けてロードオブジェクト管理情報に登録し、
前記第2の取得手段は、
前記リストに含まれる各弱参照オブジェクトの参照先である各オブジェクトを前記ヒープ領域から取得する、
請求項1に記載の情報処理装置。 - 前記第2の取得手段及び前記第3の取得手段により取得された各オブジェクトを、前記ヒープ領域以外の記憶領域に格納する格納手段をさらに備え、
前記算出手段は、前記記憶領域に格納された各オブジェクトのメモリ使用量の総和を前記合計値として算出する
請求項1又は2に記載の情報処理装置。 - 前記第3の取得手段は、前記ヒープ領域のガーベージコレクションにおいてメモリを解放しないオブジェクトを特定する処理と併せて、前記参照される全てのオブジェクトを取得する
請求項1乃至3のいずれか1項に記載の情報処理装置。 - 前記算出手段は、複数のアプリケーションについての前記メモリ使用量の合計値を算出する場合、当該複数のアプリケーション間で重複するオブジェクトについてのメモリ使用量の重複分を当該合計値から除く
請求項1乃至4のいずれか1項に記載の情報処理装置。 - 前記第2の取得手段において前記オブジェクト特定情報により前記ヒープ領域からオブジェクトが特定されない場合に、前記ロードオブジェクト管理情報から当該特定されないオブジェクトを削除する削除手段をさらに備える
請求項1乃至5のいずれか1項に記載の情報処理装置。 - 前記合計値と共に、前記第2の取得手段により取得された各オブジェクトを基点としたオブジェクトの参照関係を出力する出力手段をさらに備える
請求項1乃至6のいずれか1項に記載の情報処理装置。 - 前記第3の取得手段は、
前記取得された各オブジェクトから参照されるオブジェクトを再帰的に取得する
請求項1乃至7のいずれか1項に記載の情報処理装置。 - アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録し、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得し、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得し、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得し、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する、
情報処理装置の制御方法。 - アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する処理と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する処理と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する処理と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する処理と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する処理と、
をコンピュータに実行させるプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015009195A JP5867633B1 (ja) | 2015-01-21 | 2015-01-21 | 情報処理装置、制御方法及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015009195A JP5867633B1 (ja) | 2015-01-21 | 2015-01-21 | 情報処理装置、制御方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5867633B1 JP5867633B1 (ja) | 2016-02-24 |
JP2016134057A true JP2016134057A (ja) | 2016-07-25 |
Family
ID=55360856
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015009195A Active JP5867633B1 (ja) | 2015-01-21 | 2015-01-21 | 情報処理装置、制御方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5867633B1 (ja) |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6391754A (ja) * | 1986-10-06 | 1988-04-22 | Fujitsu Ltd | メモリサイズ制御方式 |
JPS6433642A (en) * | 1987-07-30 | 1989-02-03 | Fujitsu Ltd | Collecting system for memory application information |
JPH0231250A (ja) * | 1988-07-21 | 1990-02-01 | Toshiba Corp | タスク使用メモリサイズ割当て方式 |
JPH06103158A (ja) * | 1992-08-07 | 1994-04-15 | Internatl Business Mach Corp <Ibm> | メモリデバイスの用途決定方法及びシステム |
JPH1139203A (ja) * | 1997-07-18 | 1999-02-12 | Nec Corp | バッファ使用状況監視方式 |
JP2002073380A (ja) * | 2000-06-12 | 2002-03-12 | Fujitsu Ltd | オブジェクト指向設計性能評価装置、記録媒体及びプログラム |
US20060195823A1 (en) * | 2005-02-28 | 2006-08-31 | Sap Ag. | Memory debugging tool |
US20080046673A1 (en) * | 2006-08-16 | 2008-02-21 | International Business Machines Corporation | Method and system to optimize java virtual machine performance |
US20100211754A1 (en) * | 2009-02-13 | 2010-08-19 | Crosby Peter Anthony | Memory utilization analysis |
JP2014002443A (ja) * | 2012-06-15 | 2014-01-09 | Mitsubishi Electric Corp | 使用量算出装置及びコンピュータプログラム及び使用量算出方法 |
WO2014171002A1 (ja) * | 2013-04-19 | 2014-10-23 | 株式会社日立製作所 | メモリ管理方法、計算機及び記録媒体 |
JP2014239302A (ja) * | 2013-06-06 | 2014-12-18 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
-
2015
- 2015-01-21 JP JP2015009195A patent/JP5867633B1/ja active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6391754A (ja) * | 1986-10-06 | 1988-04-22 | Fujitsu Ltd | メモリサイズ制御方式 |
JPS6433642A (en) * | 1987-07-30 | 1989-02-03 | Fujitsu Ltd | Collecting system for memory application information |
JPH0231250A (ja) * | 1988-07-21 | 1990-02-01 | Toshiba Corp | タスク使用メモリサイズ割当て方式 |
JPH06103158A (ja) * | 1992-08-07 | 1994-04-15 | Internatl Business Mach Corp <Ibm> | メモリデバイスの用途決定方法及びシステム |
JPH1139203A (ja) * | 1997-07-18 | 1999-02-12 | Nec Corp | バッファ使用状況監視方式 |
JP2002073380A (ja) * | 2000-06-12 | 2002-03-12 | Fujitsu Ltd | オブジェクト指向設計性能評価装置、記録媒体及びプログラム |
US20060195823A1 (en) * | 2005-02-28 | 2006-08-31 | Sap Ag. | Memory debugging tool |
US20080046673A1 (en) * | 2006-08-16 | 2008-02-21 | International Business Machines Corporation | Method and system to optimize java virtual machine performance |
US20100211754A1 (en) * | 2009-02-13 | 2010-08-19 | Crosby Peter Anthony | Memory utilization analysis |
JP2014002443A (ja) * | 2012-06-15 | 2014-01-09 | Mitsubishi Electric Corp | 使用量算出装置及びコンピュータプログラム及び使用量算出方法 |
WO2014171002A1 (ja) * | 2013-04-19 | 2014-10-23 | 株式会社日立製作所 | メモリ管理方法、計算機及び記録媒体 |
JP2014239302A (ja) * | 2013-06-06 | 2014-12-18 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP5867633B1 (ja) | 2016-02-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3336688A1 (en) | Software delivery pipeline management | |
CN112835676A (zh) | 一种容器化应用的部署方法及装置、计算机设备、介质 | |
US9003240B2 (en) | Blackbox memory monitoring with a calling context memory map and semantic extraction | |
JP5618796B2 (ja) | 計算機、計算機の制御方法及びプログラム | |
JPWO2018002991A1 (ja) | 制御装置、vnf配置先選択方法及びプログラム | |
JP5031470B2 (ja) | メモリ管理方法、情報処理装置及びメモリ管理プログラム | |
CN110347590A (zh) | 业务***的接口测试控制方法及装置 | |
CN113835844B (zh) | 一种容器集群的管理方法、装置及云计算平台 | |
CN104298589B (zh) | 一种性能测试方法和设备 | |
JP5867633B1 (ja) | 情報処理装置、制御方法及びプログラム | |
CN115576903B (zh) | 一种文件***构建方法、计算设备及存储介质 | |
JP4144885B2 (ja) | アプリケーション・オブジェクトの再利用方法 | |
CN110447018B (zh) | 操作管理服务器、开发操作支持***及其方法以及存储其程序的非暂时性计算机可读介质 | |
CN110806891A (zh) | 嵌入式设备软件版本的生成方法及装置 | |
CN114625397A (zh) | 一种java代码热更新装置及方法 | |
CN109062789B (zh) | 持续集成方法、装置及设备、可读存储介质 | |
CN111367796A (zh) | 应用程序调试方法及装置 | |
CN108108180B (zh) | 一种运行时动态更新应用的方法和装置 | |
WO2011104889A1 (ja) | 計算機システム、メモリ管理方法及びメモリ管理プログラム | |
JP6010961B2 (ja) | データ参照元特定システム及びその特定方法、並びにそのコンピュータ・プログラム | |
CN110874317B (zh) | 一种生成、使用测试用例的方法及其服务器、终端 | |
KR102468381B1 (ko) | 병렬 스토리지 장치를 위한 저장매체 검사 장치 및 방법과 이를 위한 컴퓨터 프로그램 | |
US20230393964A1 (en) | System and method to dynamically select test cases based on code change contents for achieving minimal cost and adequate coverage | |
CN115495306A (zh) | 内存状态的监控方法、装置及电子设备 | |
WO2014147742A1 (ja) | エラー分析方法、情報処理装置およびエラー分析プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20151208 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20151221 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5867633 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |