(57)【要約】【課題】本発明は、複数のスレッドから参照することができるオブジェクトを、スレッドグループヒープと呼ばれるヒープに配置することによって、オブジェクトを回収するためのＧＣを実行する際に、ＧＣによる実行停止時間を削減することができるメモリ管理装置を提供することを目的とするものである。【解決手段】アプリケーションプログラムが生成するオブジェクトを、１つのスレッドと対応付けられたスレッドローカルヒープに生成し、上記生成されたオブジェクトを参照することができるスレッドが変化することに応じて、適切なスレッドグループヒープに移動させ、不要になったオブジェクトを回収する際に、上記不要になったオブジェクトを参照することができるスレッドのみを停止するメモリ管理装置である。【選択図】  図１
2004246753.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムと、実行ライブラリと、複数のヒープと、上記ヒープの内部に生成される複数のオブジェクトとによって構成されている情報処理装置において、
アプリケーションプログラムを構成している所定のスレッドが、実行ライブラリを経由してオブジェクトを生成する場合に、上記実行ライブラリが、複数の上記スレッドと対応しているヒープに、オブジェクトを生成することを特徴とするメモリ管理装置。
【請求項２】
請求項１において、
どのスレッドがどのオブジェクトを参照することができるかを管理し、所定のオブジェクトを参照することができるスレッドが変化した場合に、上記所定のオブジェクトを、上記変化したスレッドと対応しているヒープへ移動することを特徴とするメモリ管理装置。
【請求項３】
請求項１において、
不要なオブジェクトの回収を開始する際に、上記不要オブジェクトを参照することができるスレッドのみを停止することを特徴とするメモリ管理装置。
【請求項４】
アプリケーションプログラムと、実行ライブラリと、複数のヒープと、上記ヒープの内部に生成される複数のオブジェクトとによって構成されている情報処理装置を制御するプログラムにおいて、
アプリケーションプログラムを構成している所定のスレッドが、実行ライブラリを経由してオブジェクトを生成する場合に、上記実行ライブラリが、複数の上記スレッドに対応しているヒープに、オブジェクトを生成させる手順をコンピュータに実行させるプログラム。
【請求項５】
請求項４において、
どのスレッドがどのオブジェクトを参照することができるかを管理する手順と；
所定のオブジェクトを参照することができるスレッドが変化した場合に、上記所定のオブジェクトを、上記変化したスレッドと対応しているヒープへ移動する手順と；
をコンピュータに実行させるプログラム。
【請求項６】
請求項４において、
不要オブジェクトを開始する際に、上記不要オブジェクトを参照することができるスレッドのみを停止する手順をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、Ｊａｖａ（登録商標）仮想マシンを搭載した装置に関するものである。
【０００２】
【従来の技術】
既存のＪａｖａ（登録商標）技術（スレッドローカルヒープ）では、複数のスレッドのそれぞれに対応しているスレッドローカルヒープを用意し、所定のスレッドがオブジェクトを生成する際に、上記所定のスレッドに対応するヒープ上にオブジェクトを生成する。
【０００３】
上記オブジェクトの生成を命令したスレッド以外のスレッドが、上記生成されたオブジェクトを参照することができるようになると、上記生成されたオブジェクトを、スレッドローカルヒープから、通常のグローバルヒープに移動させる。
【０００４】
なお、上記スレッドローカルヒープは、１つのスレッドにのみ対応しているヒープ（スレッドと１対１に対応しているヒープ）であり、上記グローバルヒープは、全てのスレッドに対応するヒープである。また、グローバルヒープに含まれているオブジェクトは、全てのスレッドから参照することができる。
【０００５】
上記のように、上記生成されたオブジェクトを、スレッドローカルヒープから通常のグローバルヒープに移動すると、１つのスレッドから参照可能なオブジェクトのみが、スレッドローカルヒープに残る。そして、そのヒープを、ＧＣ（Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ、不要になったオブジェクトを回収する処理）を実行する際に、そのヒープに対応するスレッドのみを停止すればよい。
【０００６】
ただし、上記従来技術では、複数のスレッドが参照することができるオブジェクトは、全てグローバルヒープに配置され、グローバルヒープに配置されているオブジェクトを回収するには、全スレッドを停止する必要がある（たとえば、非特許文献１参照）。
【０００７】
【非特許文献１】
Ｔａｍａｒ  Ｄｏｍａｎｉ  ａｎｄ  Ｇａｌ  Ｇｏｌｄｓｈｔｅｉｎ  ａｎｄ  Ｅｌｌｉｏｔ  Ｋ．  Ｋｏｌｏｄｎｅｒ  ａｎｄ  Ｅｔｈａｎ  Ｌｅｗｉｓ  ａｎｄ  Ｅｒｅｚ  Ｐｅｔｒａｎｋ  ａｎｄ  Ｄａｆｎａ  Ｓｈｅｉｎｗａｌｄ  著「Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ｔｈｉｒｄ  ｉｎｔｅｒｎａｔｉｏｎａｌ  ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｍｅｍｏｒｙ  ｍａｎａｇｅｍｅｎｔ」ＡＣＭ  Ｐｒｅｓｓ出版、２００２年発行、ｐｐ７６−８７（論文タイトル：Ｔｈｒｅａｄ−ｌｏｃａｌ  ｈｅａｐｓ  ｆｏｒ  Ｊａｖａ）  ＩＳＢＮ：１−５８１１３−５３９−４
【０００８】
【発明が解決しようとする課題】
上記従来例では、複数のスレッドから参照することができるオブジェクトは、全てグローバルヒープに配置され、グローバルヒープに配置されている不要オブジェクトを回収する場合、停止する必要のないスレッドまで停止させるので、グローバルヒープに配置されているオブジェクトに対応するスレッドの実行停止時間を削減することができないという問題がある。
【０００９】
本発明は、複数のスレッドから参照することができるオブジェクトを、スレッドグループヒープ（スレッドとヒープとがｎ対１の関係にある）と呼ばれるヒープ（ｎ個のスレッドに対応する１つのヒープ）に配置することによって、オブジェクトを回収するためのＧＣを実行する際に、ＧＣによる実行停止時間を削減することができるメモリ管理装置を提供することを目的とするものである。
【００１０】
なお、上記スレッドグループヒープは、複数のスレッドに対応するヒープである。
【００１１】
【課題を解決するための手段】
本発明は、アプリケーションプログラムが生成するオブジェクトを、１つのスレッドと対応付けられたスレッドローカルヒープに生成し、上記生成されたオブジェクトを参照することができるスレッドが変化することに応じて、適切なスレッドグループヒープ（所定のオブジェクトを参照可能なスレッドの集合に対応するスレッドグループヒープ）に移動させ、不要になったオブジェクトを回収する際に、上記不要になったオブジェクトを参照することができるスレッドのみを停止するメモリ管理装置である。
【００１２】
なお、上記オブジェクトの回収は、オブジェクトが占めていたメモリ領域を開放し、メモリを再利用可能な状態にすることであり、これを、ＧＣの分野では「回収」するといい、消去とほぼ同意である。
【００１３】
【発明の実施の形態および実施例】
図１は、本発明の実施例であるメモリ管理装置１００を示すシステム構成例である。
【００１４】
メモリ管理装置１００は、オブジェクトの所有権管理を利用したメモリ管理装置であり、アプリケーションプログラムＡＰと、実行ライブラリＥＬと、ヒープＨ１、Ｈ２、……と、カードテーブルＣＴとを有する。
【００１５】
アプリケーションプログラムＡＰは、中間言語で記述され、複数のスレッドＳＬ１、ＳＬ２、……によって構成されている。各スレッドＳＬ１、ＳＬ２、……は、一意のＩＤを保持し、実際の処理を実行する。
【００１６】
実行ライブラリＥＬは、Ｊａｖａ（登録商標）仮想機械に相当し、上記中間言語を解釈し、処理を実行する。
【００１７】
ヒープＨ１、Ｈ２、……は、実行ライブラリＥＬによってメモリに確保され、所定のヒープと関連付けられているスレッドＳＬのＩＤが、ヒープのヘッダに保持されている。また、アプリケーションプログラムＡＰの要求に応じて、オブジェクトＯ１、Ｏ２、……を、ヒープ内部に保持している。
【００１８】
カードテーブルＣＴは、ヒープＨ１、Ｈ２、……のそれぞれを細かく区切った領域のそれぞれに応対するフラグを、保持している。上記フラグは、対応するヒープ領域上のオブジェクトに、他のオブジェクトのリファレンスが格納されたときに、セットされるフラグである。
【００１９】
図２は、メモリ管理装置１００におけるスレッド生成を示す図であり、Ｊａｖａ（登録商標）仮想機械上で、メモリ管理装置１００が生成された場合に、アプリケーションプログラムＡＰ内でスレッドを生成する手順を示す図である。
【００２０】
まず、アプリケーションプログラムＡＰには、スレッドとしてスレッドＳＬ１のみが生成され、ヒープとしてヒープＨ１のみが生成され、ヒープＨ１にオブジェクトＯ１が格納され、スレッドＳＬ１がオブジェクトＯ１を参照することができるとする。また、スレッドＳＬ１のＩＤが「１」であり、ヒープＨ１のヘッダＨＤ１には、スレッドＳＬ１がヒープＨ１を所有していることを示す情報「所有スレッド：１」が保持されている。
【００２１】
ステップＳ２１では、アプリケーションプログラムＡＰのスレッドＳＬ１（ＩＤ：１）が、新規スレッドＳＬ２の生成要求を、実行ライブラリＥＬに出す。
【００２２】
ステップＳ２２では、実行ライブラリＥＬが、新規スレッドＳＬ２と新規ヒープＨ２とを生成し、新規スレッドＳＬ２が新規ヒープＨ２を所有することを示すために、新規ヒープＨ２のヘッダＨＤ２に、所有スレッドとして新規スレッドＳＬ２のＩＤを保持する（「所有スレッド：２」という情報を保持する）。
【００２３】
ステップＳ２３では、新規スレッドＳＬ２の実行を開始する。
【００２４】
図３は、メモリ管理装置１００におけるオブジェクト生成を示す図であり、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合、アプリケーションプログラムＡＰが、オブジェクトを生成する手順を示す図である。
【００２５】
ステップＳ３１では、アプリケーションプログラムＡＰのスレッドＳＬ１（ＩＤ：１）が、実行ライブラリＥＬに、新規オブジェクトＯ１の生成要求を出す。
【００２６】
ステップＳ３２では、新規オブジェクトＯ１の生成を要求した要求元スレッドＳＬ１が所有するヒープＨ１に、オブジェクトＯ１を生成することを、実行ライブラリＥＬが試みる。この試みが成功すれば、処理を終了する。
【００２７】
ステップＳ３３では、オブジェクトＯ１の生成に失敗すれば、そのヒープＨ１内で、図６で後述するごみ集めを実行し、その後に、オブジェクト生成を再度試みる。なお、ヒープの空き領域が不足すると、オブジェクトの生成を失敗するので、ごみ集め（不要なオブジェクトを回収すること）によって、オブジェクト生成のための空き領域を確保する。
【００２８】
そして、オブジェクト生成を再度試みた結果、オブジェクト生成を再び失敗すれば、例外を発生させ、異常が発生したことをアプリケーションプログラムＡＰに通知する。なお、上記例外は、Ｊａｖａ（登録商標）仮想機械の仕様で定義されている。
【００２９】
図４は、メモリ管理装置１００におけるリファレンス設定を示す図であり、Ｊａｖａ（登録商標）仮想機械上で、メモリ管理装置１００が生成された場合に、アプリケーションプログラムＡＰがリファレンス設定する手順を示す図である。
【００３０】
なお、上記「リファレンス設定」は、オブジェクトの参照元に、参照先の情報（リファレンス）を設定する動作である。
【００３１】
ステップＳ４１では、アプリケーションプログラムＡＰのスレッドＳＬ１（ＩＤ：１）が、所定のオブジェクトのリファレンスを、他のオブジェクトに保存する要求を、実行ライブラリＥＬに出す。
【００３２】
ステップＳ４２では、実行ライブラリＥＬが、図４に示す保存先オブジェクトＯ１１のリファレンスを、保存元オブジェクトＯ１に保存する。
【００３３】
ここで、Ｄｉｒｔｙレコードは、カードテーブルＣＴを構成する複数のレコードのうちで所定のレコードであって、保存先オブジェクトＯ１１が格納されているヒープ領域に対応するレコードである。なお、Ｄｉｒｔｙカードは、ヒープをいくつかの領域（レコード）に分割し、この分割された領域（レコード）に対応するフラグであり、Ｄｉｒｔｙレコードであるか、そうでないレコードであるかを示すフラグである。また、ＤｉｒｔｙカードにＤｉｒｔｙレコードを設定する。
【００３４】
図５は、上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合、アプリケーションプログラムＡＰ内でごみ集め（ＧＣ（Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ））する前に、各オブジェクトの所有権を更新する手順を示す図である。
【００３５】
ステップＳ５１では、実行ライブラリＥＬが、カードテーブルＣＴを順番に検索し、Ｄｉｒｔｙレコードを検出し、この検出されたＤｉｒｔｙレコードに対応するヒープ領域上のオブジェクト（たとえば、オブジェクトＯ３）に格納されているリファレンスを取得する。
【００３６】
ステップＳ５２では、オブジェクトＯ３に格納されているリファレンスが、スレッドＳＬ１に所有されているヒープＨ１上のオブジェクトＯ１を指している場合、オブジェクトＯ１の所有スレッド（追加前はスレッドＳＬ１のみ）に、ヒープＨ３を所有するスレッドＳＬ１、ＳＬ２が追加され、この追加後の所有スレッドＳＬ１、ＳＬ２に対応するヒープＨ３に、当該オブジェクトＯ１を移動する。この移動されたオブジェクトが、オブジェクトＯ３１である。
【００３７】
なお、適切なヒープ（変化したスレッドと対応しているヒープであり、上記実施例では、ヒープＨ３である）が存在しなければ、ヒープを新規生成する。
【００３８】
ステップＳ５３では、カードテーブルＣＴに格納されているレコードの中から、Ｄｉｒｔｙレコードを全て検出し終わると、上記ステップＳ５１に戻る。
【００３９】
図６は、上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合に、実行ライブラリＥＬがごみ集めする手順を示す図である。
【００４０】
ステップＳ６１では、ごみ集めの対象ヒープと同サイズのヒープ（以下、「コピー先ヒープ」という）を用意する。なお、上記ごみ集めの対象ヒープは、オブジェクト生成に失敗したヒープであり、このオブジェクト生成に失敗したヒープについてごみ集めが実行される。
【００４１】
ステップＳ６２では、実行ライブラリＥＬが、全スレッドを停止する。すなわち、ごみ集めの実行時にリファレンスが変更される可能性があるので、全スレッドを停止する。
【００４２】
ステップＳ６３では、カードテーブルＣＴに格納されているＤｉｒｔｙレコードを検索し、図５に示すように、スレッドがヒープを所有する所有権を更新し、これと同時に、上記検索されたＤｉｒｔｙレコードに対応するヒープ領域上のオブジェクトに格納されているリファレンスのうちで、対象ヒープＨ３を参照するリファレンスを、ごみ集めのための集合  （ごみ集め開始時は空集合である）に加える。
【００４３】
ステップＳ６４では、上記対象ヒープＨ３を所有するスレッドＳＬ１、ＳＬ２が保持するスタック上のリファレンス（オブジェクトへのリファレンス）のうちで、対象ヒープＨ３へのリファレンスを、上記ごみ集めのための集合に加える。
【００４４】
ステップＳ６５では、実行ライブラリＥＬが、対象ヒープ上のオブジェクトＯ３１を所有するスレッド以外のスレッドを再開する。
【００４５】
ステップＳ６６において、オブジェクトＯ２からオブジェクトＯ３へのリファレンスを取り出した場合、この取り出したリファレンスを辿り、辿った先のオブジェクトＯ３を、コピー先ヒープＨ４にコピーし、そのオブジェクトＯ３が含む対象ヒープＨ３のリファレンスを、集合へ加える。また、元々のオブジェクトＯ３の位置に、コピー先のアドレスを記録する。さらに、辿った元のリファレンスを、コピー先へのリファレンスに置き換える。また、リファレンスを辿る際に、コピー先のアドレスが保存してある場合、そのリファレンスをコピー先のリファレンスへ置き換える。
【００４６】
ステップＳ６７では、集合がなくなるまで、上記ステップＳ６６の動作を繰り返す。
【００４７】
ステップＳ６８では、コピー元となるヒープＨ３を解放する。つまり、ヒープＨ３に含まれているオブジェクトと、そのヒープＨ３とを消去し、ＯＳ等の外部システム側で再利用できる状態にする。
【００４８】
図７は、上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合に、実行ライブラリＥＬがスレッドを消去する手順を示す図である。
【００４９】
上記実行ライブラリＥＬによるスレッド消去は、Ｊａｖａ（登録商標）仮想機械仕様に含まれるスレッド関係の機能の１つである。
【００５０】
ステップＳ７１では、アプリケーションプログラムＡＰが、スレッドＳＬ２の終了要求を実行ライブラリＥＬに出す。
【００５１】
ステップＳ７２では、実行ライブラリＥＬは、対象スレッドＳＬ２を消去し、上記対象スレッドＳＬ２のみが所有していたヒープＨ２を解放する。ヒープＨ２を解放する場合、たとえば、一般的なシステムライブラリであるＡＮＳＩＣライブラリのｆｒｅｅを呼び出すことによって、ヒープＨ２を解放する。また、ヒープＨ２以外のヒープのヘッダから、上記対象スレッドＳＬ２のＩＤを消去する。
【００５２】
ところで、上記従来例では、グローバルヒープに配置されているオブジェクトのうちで回収する必要のあるオブジェクトが存在する場合、このオブジェクトを回収するには、グローバルヒープに配置されている全てのオブジェクトに対応する全てのスレッドを停止する必要があり、スレッドの実行停止時間が長い。
【００５３】
ところが、上記実施例によれば、複数のスレッドから参照することができるオブジェクトを、スレッドグループヒープと呼ばれるヒープに配置することによって、スレッドグループヒープに配置されているオブジェクトを回収するためのガーベジコレクションを実行する際に、全スレッドを停止するのではなく、上記スレッドグループヒープ内のオブジェクトを参照することができるスレッドのみを停止すれば充分であり、ガーベジコレクションによる実行停止時間を削減することができる。
【００５４】
すなわち、上記実施例によれば、スレッドに対応しているヒープに、オブジェクトを生成するので、ＧＣ（ガーベジコレクション）中に停止する必要のあるスレッド数を削減することができ、したがって、実行停止時間を削減することができる。つまり、不要なオブジェクトの回収を開始する際に、従来例では、全てのスレッドを停止させるが、上記実施例では、不要オブジェクトを参照することができるスレッドのみを停止させ、停止する必要のあるスレッド数を削減することにより、みかけ上の実行停止時間を削減することができる。
【００５５】
なお、上記実施例をプログラムの発明として把握することができる．つまり、上記実施例は、アプリケーションプログラムと、実行ライブラリと、複数のヒープと、上記ヒープの内部に生成される複数のオブジェクトとによって構成されている情報処理装置を制御するプログラムにおいて、アプリケーションプログラムを構成している所定のスレッドが、実行ライブラリを経由してオブジェクトを生成する場合に、上記実行ライブラリが、複数の上記スレッドに対応しているヒープに、オブジェクトを生成させる手順をコンピュータに実行させるプログラムの例である。
【００５６】
このプログラムは、どのスレッドがどのオブジェクトを参照することができるかを管理する手順と、所定のオブジェクトを参照することができるスレッドが変化した場合に、上記所定のオブジェクトを、上記変化したスレッドと対応しているヒープへ移動する手順とをコンピュータに実行させる。
【００５７】
また、上記プログラムは、不要オブジェクトを開始する際に、上記不要オブジェクトを参照することができるスレッドのみを停止する手順をコンピュータに実行させる。
【００５８】
【発明の効果】
本発明によれば、実行ライブラリがアプリケーションプログラムのスレッドとヒープとを対応付けることによって、ごみ集めによる全スレッドの停止時間を削減することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明の実施例であるメモリ管理装置１００を示すシステム構成例である。
【図２】メモリ管理装置１００におけるスレッド生成を示す図であり、Ｊａｖａ（登録商標）仮想機械上で、メモリ管理装置１００が生成された場合に、アプリケーションプログラムＡＰ内でスレッドを生成する手順を示す図である。
【図３】メモリ管理装置１００におけるオブジェクト生成を示す図であり、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合、アプリケーションプログラムＡＰが、オブジェクトを生成する手順を示す図である。
【図４】メモリ管理装置１００におけるリファレンス設定を示す図であり、Ｊａｖａ（登録商標）仮想機械上で、メモリ管理装置１００が生成された場合に、アプリケーションプログラムＡＰがリファレンス設定する手順を示す図である。
【図５】上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合、アプリケーションプログラムＡＰ内でごみ集めする前に、各オブジェクトの所有権を更新する手順を示す図である。
【図６】上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合に、実行ライブラリＥＬがごみ集めする手順を示す図である。
【図７】上記実施例において、Ｊａｖａ（登録商標）仮想機械上でメモリ管理装置１００が生成された場合に、実行ライブラリＥＬがスレッドを消去する手順を示す図である。
【符号の説明】
１００…メモリ管理装置、
ＡＰ…アプリケーションプログラム、
ＳＬ１、ＳＬ２…スレッド、
ＥＬ…実行ライブラリ、
Ｈ１、Ｈ２、Ｈ３…ヒープ、
ＨＤ１、ＨＤ２、ＨＤ３…ヘッダ、
Ｏ１、Ｏ２、Ｏ３、Ｏ１１、Ｏ３１…オブジェクト、
ＣＴ…カードテーブル。
【図１】
2004246753.tif 000003
【図２】
2004246753.tif 000004
【図３】
2004246753.tif 000005
【図４】
2004246753.tif 000006
【図５】
2004246753.tif 000007
【図６】
2004246753.tif 000008
【図７】
2004246753.tif 000009