JP2000222221A - コンパイル方法および装置、並びにメソッド活動度計算方法および装置 - Google Patents
コンパイル方法および装置、並びにメソッド活動度計算方法および装置Info
- Publication number
- JP2000222221A JP2000222221A JP11022030A JP2203099A JP2000222221A JP 2000222221 A JP2000222221 A JP 2000222221A JP 11022030 A JP11022030 A JP 11022030A JP 2203099 A JP2203099 A JP 2203099A JP 2000222221 A JP2000222221 A JP 2000222221A
- Authority
- JP
- Japan
- Prior art keywords
- call
- activity
- code
- stack
- map
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Devices For Executing Special Programs (AREA)
- Executing Machine-Instructions (AREA)
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】
【課題】 コード破棄するメソッドを効果的に選択する
ためにメソッド活動度を計算する方法を提供する。 【解決の手段】 コンパイル時に、メソッド中で生じ得
るメソッド呼び出しに関する呼び出しマップを作成し且
つ記憶装置に格納し、実際に生じたメソッド呼び出しを
記録するコードを生成し且つ記憶装置に格納する。この
ような状態において、コードの回収する際には、全スレ
ッドを一時停止し、あるメソッドが実行される可能性の
高低を表す活動度を計算する。この時、スタックフレー
ムに対応する第１メソッドについての、呼び出しマップ
と実際に生じたメソッド呼び出しに関する情報とを用い
て、第１メソッドから呼ばれる可能性が高い第２メソッ
ドを特定し且つ記憶装置に格納し、第１メソッドに対応
するスタックフレームのスタックの最上部からの段数に
応じた優先度を第２メソッドの活動度に作用することに
より第２メソッドの活動度を更新する。好適には、この
ような処理を繰り返す。その後活動度が低いメソッドの
コードを破棄する。
ためにメソッド活動度を計算する方法を提供する。 【解決の手段】 コンパイル時に、メソッド中で生じ得
るメソッド呼び出しに関する呼び出しマップを作成し且
つ記憶装置に格納し、実際に生じたメソッド呼び出しを
記録するコードを生成し且つ記憶装置に格納する。この
ような状態において、コードの回収する際には、全スレ
ッドを一時停止し、あるメソッドが実行される可能性の
高低を表す活動度を計算する。この時、スタックフレー
ムに対応する第１メソッドについての、呼び出しマップ
と実際に生じたメソッド呼び出しに関する情報とを用い
て、第１メソッドから呼ばれる可能性が高い第２メソッ
ドを特定し且つ記憶装置に格納し、第１メソッドに対応
するスタックフレームのスタックの最上部からの段数に
応じた優先度を第２メソッドの活動度に作用することに
より第２メソッドの活動度を更新する。好適には、この
ような処理を繰り返す。その後活動度が低いメソッドの
コードを破棄する。
Description
【０００１】
【発明の属する技術分野】本発明は、コード破棄するメ
ソッドを効果的に選択するためのメソッド活動度計算方
法に関係し、特に、Ｊａｖａ（Ｓｕｎ Ｍｉｃｒｏｓｙ
ｓｔｅｍｓ社の商標）のＪＩＴ（Ｊｕｓｔ Ｉｎ Ｔｉ
ｍｅ）コンパイラにおけるメソッド活動度計算方法に関
係する。
ソッドを効果的に選択するためのメソッド活動度計算方
法に関係し、特に、Ｊａｖａ（Ｓｕｎ Ｍｉｃｒｏｓｙ
ｓｔｅｍｓ社の商標）のＪＩＴ（Ｊｕｓｔ Ｉｎ Ｔｉ
ｍｅ）コンパイラにおけるメソッド活動度計算方法に関
係する。
【０００２】
【従来の技術】現在、Ｊａｖａは、ネットワークコンピ
ューティングの共通言語としてだけでなく、プラットフ
ォームに依存しない、オブジェクト指向言語のスタンダ
ードな言語として広く使用されている。Ｊａｖａで書か
れたプログラムはバイトコードに変換され、バイトコー
ドはＪａｖａ仮想マシンで実行される。そのため、一度
Ｊａｖａで書かれたプログラムは、Ｊａｖａをサポート
しているコンピュータならば、ＣＰＵを問わずどこでも
動く（マルチプラットフォーム）という利点を持つ。
ューティングの共通言語としてだけでなく、プラットフ
ォームに依存しない、オブジェクト指向言語のスタンダ
ードな言語として広く使用されている。Ｊａｖａで書か
れたプログラムはバイトコードに変換され、バイトコー
ドはＪａｖａ仮想マシンで実行される。そのため、一度
Ｊａｖａで書かれたプログラムは、Ｊａｖａをサポート
しているコンピュータならば、ＣＰＵを問わずどこでも
動く（マルチプラットフォーム）という利点を持つ。
【０００３】しかしこうした利点の反面、バイトコード
の仮想マシンによる実行は、機械語のコードを直接実行
するのに比べて、実行性能の点で劣る。そのため、ＪＩ
Ｔコンパイラにより、Ｊａｖａプログラムの動作中に前
記バイトコードを機械語コード（以下、ＪＩＴｅｄコー
ドと呼ぶ）に変換して、バイトコードの代わりにＪＩＴ
ｅｄコードを実行するのが一般的である。コンパイルの
最小単位は、メソッドと呼ばれるサブルーチンである。
実行頻度の高いコードを機械語に変換することにより、
Ｊａｖａバイトコードのマルチプラットフォーム特性を
残しつつ、機械語コードの性能を引き出している。
の仮想マシンによる実行は、機械語のコードを直接実行
するのに比べて、実行性能の点で劣る。そのため、ＪＩ
Ｔコンパイラにより、Ｊａｖａプログラムの動作中に前
記バイトコードを機械語コード（以下、ＪＩＴｅｄコー
ドと呼ぶ）に変換して、バイトコードの代わりにＪＩＴ
ｅｄコードを実行するのが一般的である。コンパイルの
最小単位は、メソッドと呼ばれるサブルーチンである。
実行頻度の高いコードを機械語に変換することにより、
Ｊａｖａバイトコードのマルチプラットフォーム特性を
残しつつ、機械語コードの性能を引き出している。
【０００４】メソッドのＪＩＴｅｄコードは、プログラ
ムが動作するＣＰＵに適したコードになっているという
点で、Ｃコンパイラなどが生成する最適化コードと同等
である。一般に、現在普及しているＣＰＵでは、サブル
ーチンが呼ばれると、サブルーチンは、自分が使用する
ローカル変数を格納するための領域（フレームと呼ぶ）
をスタック状に形成する。図１は、サブルーチンＡがサ
ブルーチンＢを、サブルーチンＢがサブルーチンＣを呼
び出したときのスタックの様子である。この図におい
て、スタックは下から上に伸びる。各領域は、サブルー
チンのそれぞれのフレームを表わす。各サブルーチンか
ら戻る際、フレームは除去される。Ｊａｖａでは、スレ
ッドと呼ばれる実行単位毎にＣＰＵ資源が割り振られ、
１つのスレッドは固有のスタック（スレッドスタックと
呼ぶ）を持つ。ＪＩＴｅｄコードは、スレッドスタック
上に上述したようなフレーム（以下、ＪＩＴｅｄフレー
ムと呼ぶ）を作る。
ムが動作するＣＰＵに適したコードになっているという
点で、Ｃコンパイラなどが生成する最適化コードと同等
である。一般に、現在普及しているＣＰＵでは、サブル
ーチンが呼ばれると、サブルーチンは、自分が使用する
ローカル変数を格納するための領域（フレームと呼ぶ）
をスタック状に形成する。図１は、サブルーチンＡがサ
ブルーチンＢを、サブルーチンＢがサブルーチンＣを呼
び出したときのスタックの様子である。この図におい
て、スタックは下から上に伸びる。各領域は、サブルー
チンのそれぞれのフレームを表わす。各サブルーチンか
ら戻る際、フレームは除去される。Ｊａｖａでは、スレ
ッドと呼ばれる実行単位毎にＣＰＵ資源が割り振られ、
１つのスレッドは固有のスタック（スレッドスタックと
呼ぶ）を持つ。ＪＩＴｅｄコードは、スレッドスタック
上に上述したようなフレーム（以下、ＪＩＴｅｄフレー
ムと呼ぶ）を作る。
【０００５】メソッドは、最初ほとんどの場合インタプ
リタで実行されるが、実行頻度あるいは実行時間におい
てある水準以上実行されると判断されると、ＪＩＴコン
パイラによりコンパイルされる。ＪＩＴｅｄコードは一
度生成されると、メモリ中に管理される。それらを安全
に捨てることができるということＪａｖａシステムが保
証する時期は、Ｊａｖａシステムがガベージコレクショ
ン（以下、ＧＣ）によってクラスを破棄する（以下、ク
ラスアンロード）ときである。
リタで実行されるが、実行頻度あるいは実行時間におい
てある水準以上実行されると判断されると、ＪＩＴコン
パイラによりコンパイルされる。ＪＩＴｅｄコードは一
度生成されると、メモリ中に管理される。それらを安全
に捨てることができるということＪａｖａシステムが保
証する時期は、Ｊａｖａシステムがガベージコレクショ
ン（以下、ＧＣ）によってクラスを破棄する（以下、ク
ラスアンロード）ときである。
【０００６】ＪＩＴｅｄコードを含むＪＩＴコンパイラ
が使用するメモリに制限がある、あるいは制限を設ける
とき、クラスアンロードだけでは十分ではない場合があ
る。例えば、ハードディスクによる仮想記憶を持たな
い、ネットワークコンピューティング（Ｎｅｔｗｏｒｋ
Ｃｏｍｐｕｔｉｎｇ）マシン（以下、ＮＣマシン）の
ような、シンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）
上で動作するデスクトップ環境では、メモリ制限は現実
的な問題である。そのようなデスクトップ環境では、メ
ール、ワープロ、スケジューラ等、複数のＪａｖａアプ
リケーションが同時に起動され、数千種類のメソッドが
呼ばれうるが、かなりの割合のメソッドが各スレッドス
タック中に存在しない（アクティブでない）。クラスア
ンロードは、Ｊａｖａシステム内に完全に使用される可
能性のないクラスおよびそのメソッドしか破棄しないた
め、そうしたアクティブでないメソッドのＪＩＴｅｄコ
ードを破棄しない。そこでＪＩＴコンパイラはＪＩＴｅ
ｄコード破棄メカニズムを持っている。
が使用するメモリに制限がある、あるいは制限を設ける
とき、クラスアンロードだけでは十分ではない場合があ
る。例えば、ハードディスクによる仮想記憶を持たな
い、ネットワークコンピューティング（Ｎｅｔｗｏｒｋ
Ｃｏｍｐｕｔｉｎｇ）マシン（以下、ＮＣマシン）の
ような、シンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）
上で動作するデスクトップ環境では、メモリ制限は現実
的な問題である。そのようなデスクトップ環境では、メ
ール、ワープロ、スケジューラ等、複数のＪａｖａアプ
リケーションが同時に起動され、数千種類のメソッドが
呼ばれうるが、かなりの割合のメソッドが各スレッドス
タック中に存在しない（アクティブでない）。クラスア
ンロードは、Ｊａｖａシステム内に完全に使用される可
能性のないクラスおよびそのメソッドしか破棄しないた
め、そうしたアクティブでないメソッドのＪＩＴｅｄコ
ードを破棄しない。そこでＪＩＴコンパイラはＪＩＴｅ
ｄコード破棄メカニズムを持っている。
【０００７】実行中のスレッドの現在のコンテキスト
（プログラムカウンタ（ｐｒｏｇｒａｍ ｃｏｕｎｔｅ
ｒ）やスタックポインタ（ｓｔａｃｋ ｐｏｉｎｔｅ
ｒ）などＣＰＵ資源のコピー）あるいはそのスレッドス
タック中に保持されるＪＩＴｅｄコードのフレームに
は、そのスレッドでのアクティブなメソッドが記録され
ている。アクティブなメソッドのＪＩＴｅｄコードが破
棄されると、スレッドが実行できない。したがって、破
棄するのは、非アクティブなＪＩＴｅｄコードである。
ＪＩＴｅｄコード破棄メカニズムにおいて最も簡単な破
棄の仕方は、アクティブでないＪＩＴｅｄコードをすべ
て破棄する方法である。しかし、この方法では必要以上
にＪＩＴｅｄコードを破棄してしまい、無駄である。メ
ソッドの最適化コンパイルには時間がかかるため、「す
ぐに実行されるメソッドを破棄しない」という方針の下
で選択的に破棄すべきである。的確な選択の効果の例と
して、ＪＩＴｅｄコード破棄が今行われ、すぐに実行さ
れるメソッドＡと、１０分後に実行されるメソッドＢが
あったとする。もしＡを破棄すると、今破棄したＡのＪ
ＩＴｅｄコードのメモリ量と、さらにＡのコンパイルに
必要なワークのメモリ量とを、直ちに確保しなければな
らない。一方、Ｂを破棄すれば、１０分間はＢのＪＩＴ
ｅｄコードのメモリ量は、利用可能メモリとなる。実際
には必要なフリーメモリ量分の複数のＪＩＴｅｄコード
を破棄する。理想的な破棄の方針は、今後使用されない
ＪＩＴｅｄコードを破棄することであるが、このような
情報は普通得られない。類推し、しばらく呼ばれそうに
ない順にＪＩＴｅｄコードを破棄するのが現実的であ
る。以下、これをＪＩＴｅｄコード破棄方針と呼ぶ。
（プログラムカウンタ（ｐｒｏｇｒａｍ ｃｏｕｎｔｅ
ｒ）やスタックポインタ（ｓｔａｃｋ ｐｏｉｎｔｅ
ｒ）などＣＰＵ資源のコピー）あるいはそのスレッドス
タック中に保持されるＪＩＴｅｄコードのフレームに
は、そのスレッドでのアクティブなメソッドが記録され
ている。アクティブなメソッドのＪＩＴｅｄコードが破
棄されると、スレッドが実行できない。したがって、破
棄するのは、非アクティブなＪＩＴｅｄコードである。
ＪＩＴｅｄコード破棄メカニズムにおいて最も簡単な破
棄の仕方は、アクティブでないＪＩＴｅｄコードをすべ
て破棄する方法である。しかし、この方法では必要以上
にＪＩＴｅｄコードを破棄してしまい、無駄である。メ
ソッドの最適化コンパイルには時間がかかるため、「す
ぐに実行されるメソッドを破棄しない」という方針の下
で選択的に破棄すべきである。的確な選択の効果の例と
して、ＪＩＴｅｄコード破棄が今行われ、すぐに実行さ
れるメソッドＡと、１０分後に実行されるメソッドＢが
あったとする。もしＡを破棄すると、今破棄したＡのＪ
ＩＴｅｄコードのメモリ量と、さらにＡのコンパイルに
必要なワークのメモリ量とを、直ちに確保しなければな
らない。一方、Ｂを破棄すれば、１０分間はＢのＪＩＴ
ｅｄコードのメモリ量は、利用可能メモリとなる。実際
には必要なフリーメモリ量分の複数のＪＩＴｅｄコード
を破棄する。理想的な破棄の方針は、今後使用されない
ＪＩＴｅｄコードを破棄することであるが、このような
情報は普通得られない。類推し、しばらく呼ばれそうに
ない順にＪＩＴｅｄコードを破棄するのが現実的であ
る。以下、これをＪＩＴｅｄコード破棄方針と呼ぶ。
【０００８】通常考えられるメソッドのプロファイル
に、実行頻度（何回呼ばれたか）と実行時間（プログラ
ムカウンタがそのメソッドを指していた時間）がある。
実行頻度の収集は、メソッドが呼ばれる毎にそのメソッ
ドのカウンタを増加させて行なう。メソッドがＪＩＴコ
ンパイラによるコンパイルされると、それまでインタプ
リタで測定されていた実行頻度の更新は終了し、したが
ってインタプリタからはＪＩＴｅｄコードに対する実行
頻度情報は得られない。ＪＩＴｅｄコードで実行頻度情
報を得るには、各メソッドのＪＩＴｅｄコードのプロロ
ーグで実行回数を数える必要がある。例えば、ｘ８６プ
ラットフォームでは、inc dword ptr ［カウンタアドレ
ス］命令を追加する。実行時間の収集は、一定時間毎に
割り込み（典型的にはタイマ割り込み、プロセッサによ
っては実行命令数割り込み）をかけ、プログラムカウン
タ（以下、ｐｃ）を収集して行なう。
に、実行頻度（何回呼ばれたか）と実行時間（プログラ
ムカウンタがそのメソッドを指していた時間）がある。
実行頻度の収集は、メソッドが呼ばれる毎にそのメソッ
ドのカウンタを増加させて行なう。メソッドがＪＩＴコ
ンパイラによるコンパイルされると、それまでインタプ
リタで測定されていた実行頻度の更新は終了し、したが
ってインタプリタからはＪＩＴｅｄコードに対する実行
頻度情報は得られない。ＪＩＴｅｄコードで実行頻度情
報を得るには、各メソッドのＪＩＴｅｄコードのプロロ
ーグで実行回数を数える必要がある。例えば、ｘ８６プ
ラットフォームでは、inc dword ptr ［カウンタアドレ
ス］命令を追加する。実行時間の収集は、一定時間毎に
割り込み（典型的にはタイマ割り込み、プロセッサによ
っては実行命令数割り込み）をかけ、プログラムカウン
タ（以下、ｐｃ）を収集して行なう。
【０００９】ＪＩＴｅｄコード破棄方針として、これら
従来のプロファイルを使用すると問題が生じる。まず、
実行頻度について、各メソッドのＪＩＴｅｄコード実行
の度にメモリを参照してカウントするのは、メモリが枯
渇しない状態へのオーバヘッドになり、問題である。さ
らに、頻度が少ないが直ちに呼ばれるメソッドを誤って
破棄してしまう恐れがある。知りたいのは、呼ばれずに
メモリを占めているＪＩＴｅｄコードであるから、目的
に合わない。また実行時間についても、割り込みと収集
したｐｃの管理（すぐにメソッドに対応づけるなら対応
づけのコスト、対応づけないならその保存）は、メモリ
が枯渇しない状態へのオーバヘッドになり問題である。
さらに実行頻度収集の場合と同様、実行時間が短いが直
ちに呼ばれるメソッドを誤って破棄してしまう恐れがあ
る。
従来のプロファイルを使用すると問題が生じる。まず、
実行頻度について、各メソッドのＪＩＴｅｄコード実行
の度にメモリを参照してカウントするのは、メモリが枯
渇しない状態へのオーバヘッドになり、問題である。さ
らに、頻度が少ないが直ちに呼ばれるメソッドを誤って
破棄してしまう恐れがある。知りたいのは、呼ばれずに
メモリを占めているＪＩＴｅｄコードであるから、目的
に合わない。また実行時間についても、割り込みと収集
したｐｃの管理（すぐにメソッドに対応づけるなら対応
づけのコスト、対応づけないならその保存）は、メモリ
が枯渇しない状態へのオーバヘッドになり問題である。
さらに実行頻度収集の場合と同様、実行時間が短いが直
ちに呼ばれるメソッドを誤って破棄してしまう恐れがあ
る。
【００１０】
【発明が解決しようとする課題】上述のように、従来の
プロファイル手法をＪＩＴｅｄコード破棄方針とするの
は的外れで、不適切なＪＩＴｅｄコード破棄が起きる可
能性がある。本発明の目的は、コード破棄するメソッド
を効果的に選択するために、メソッドがすぐに実行され
やすいことを表わすメソッド活動度を計算する方法を提
供することである。
プロファイル手法をＪＩＴｅｄコード破棄方針とするの
は的外れで、不適切なＪＩＴｅｄコード破棄が起きる可
能性がある。本発明の目的は、コード破棄するメソッド
を効果的に選択するために、メソッドがすぐに実行され
やすいことを表わすメソッド活動度を計算する方法を提
供することである。
【００１１】
【課題を解決するための手段】本発明は上記課題を解決
するため、コンパイル時に、メソッド中で生じ得るメソ
ッド呼び出しに関する呼び出しマップを作成し且つ記憶
装置に格納し、実際に生じたメソッド呼び出しを記録す
るコードを生成し且つ記憶装置に格納する。この呼び出
しマップは、好適には、メソッド中のあるアドレスに対
し、当該アドレス以降に生じ得るメソッド呼び出しを出
力するように構成される。但し、メソッドごとにメソッ
ド呼び出しを出力するようにしてもよい。コンパイルが
終了し且つ生成されたコードが実行されると、メソッド
中で生じ得るメソッド呼び出しに関する呼び出しマップ
と実際に生じたメソッド呼び出しに関する情報とが各メ
ソッドごとに記録されるようになる。
するため、コンパイル時に、メソッド中で生じ得るメソ
ッド呼び出しに関する呼び出しマップを作成し且つ記憶
装置に格納し、実際に生じたメソッド呼び出しを記録す
るコードを生成し且つ記憶装置に格納する。この呼び出
しマップは、好適には、メソッド中のあるアドレスに対
し、当該アドレス以降に生じ得るメソッド呼び出しを出
力するように構成される。但し、メソッドごとにメソッ
ド呼び出しを出力するようにしてもよい。コンパイルが
終了し且つ生成されたコードが実行されると、メソッド
中で生じ得るメソッド呼び出しに関する呼び出しマップ
と実際に生じたメソッド呼び出しに関する情報とが各メ
ソッドごとに記録されるようになる。
【００１２】このような状態において、コードを回収す
る際には、全スレッドを一時停止し、あるメソッドが実
行される可能性の高低を表す活動度を計算する。この
時、スタックフレームに対応する第１メソッドについて
の、呼び出しマップと実際に生じたメソッド呼び出しに
関する情報とを用いて、第１メソッドから呼ばれる可能
性が高い第２メソッドを特定し且つ記憶装置に格納し、
第１メソッドに対応するスタックフレームのスタックの
最上部からの段数に応じた優先度を第２メソッドの活動
度に作用することにより第２メソッドの活動度を更新す
る。好適には、このような処理を繰り返す。すなわち、
第２メソッドについての、呼び出しマップと実際に生じ
たメソッド呼び出しに関する情報と用いて、第２メソッ
ドから呼ばれる可能性が高い第３メソッドを特定し且つ
記憶装置に格納し、第１メソッドに対応するスタックフ
レームのスタックの最上部からの段数に応じた優先度を
第３メソッドの活動度に作用することにより第３メソッ
ドの活動度を更新する。このようにして求められたメソ
ッドの活動度が低いもののコードを破棄するとより効率
的なコード破棄が行える。
る際には、全スレッドを一時停止し、あるメソッドが実
行される可能性の高低を表す活動度を計算する。この
時、スタックフレームに対応する第１メソッドについて
の、呼び出しマップと実際に生じたメソッド呼び出しに
関する情報とを用いて、第１メソッドから呼ばれる可能
性が高い第２メソッドを特定し且つ記憶装置に格納し、
第１メソッドに対応するスタックフレームのスタックの
最上部からの段数に応じた優先度を第２メソッドの活動
度に作用することにより第２メソッドの活動度を更新す
る。好適には、このような処理を繰り返す。すなわち、
第２メソッドについての、呼び出しマップと実際に生じ
たメソッド呼び出しに関する情報と用いて、第２メソッ
ドから呼ばれる可能性が高い第３メソッドを特定し且つ
記憶装置に格納し、第１メソッドに対応するスタックフ
レームのスタックの最上部からの段数に応じた優先度を
第３メソッドの活動度に作用することにより第３メソッ
ドの活動度を更新する。このようにして求められたメソ
ッドの活動度が低いもののコードを破棄するとより効率
的なコード破棄が行える。
【００１３】なお、好適には、呼び出しマップは、メソ
ッド中のあるアドレスに対し、当該アドレス以降に生じ
得るメソッド呼び出しを出力し、第２メソッドの特定
は、第１メソッドの実行再開アドレス以降に生じ得るメ
ソッド呼び出しを用いて行われる。
ッド中のあるアドレスに対し、当該アドレス以降に生じ
得るメソッド呼び出しを出力し、第２メソッドの特定
は、第１メソッドの実行再開アドレス以降に生じ得るメ
ソッド呼び出しを用いて行われる。
【００１４】本発明では、非アクティブメソッドについ
て、現在のコンテキスト、プログラムの構造、実行時情
報を利用して、すぐに呼ばれる度合い（活動度）を求め
る。ここでいう、現在のコンテキストの利用とは、スタ
ック上位（トップに近い）にあるメソッドほど早く実行
されそうだと判断できることである。プログラムの構造
の利用とは、コントロールフロー上、一時停止している
メソッドから今後呼ばれそうなメソッドを知ることであ
る。実行時情報の利用とは、前記呼ばれそうなメソッド
でも（インタプリタを含めた）実行時に一度も呼ばれて
いなければ、判断対象から除外できるということであ
る。早く呼ばれそうなメソッドの活動度が、その呼ばれ
る早さに応じて上げられる。
て、現在のコンテキスト、プログラムの構造、実行時情
報を利用して、すぐに呼ばれる度合い（活動度）を求め
る。ここでいう、現在のコンテキストの利用とは、スタ
ック上位（トップに近い）にあるメソッドほど早く実行
されそうだと判断できることである。プログラムの構造
の利用とは、コントロールフロー上、一時停止している
メソッドから今後呼ばれそうなメソッドを知ることであ
る。実行時情報の利用とは、前記呼ばれそうなメソッド
でも（インタプリタを含めた）実行時に一度も呼ばれて
いなければ、判断対象から除外できるということであ
る。早く呼ばれそうなメソッドの活動度が、その呼ばれ
る早さに応じて上げられる。
【００１５】このように活動度は、メソッドの再実行時
刻が早いほど、その値が大きい。これは、上述したＪＩ
Ｔｅｄコード破棄方針をよく模倣する点で優れている。
先ほどの例でいえば、仮にＡがスタック上位、Ｂがスタ
ック下位からそれぞれ呼ばれるメソッドであれば、本発
明のアルゴリズムによってＡの活動度はＢの活動度より
高くなり、Ｂより先にＡを選んで破棄することはなくな
る。
刻が早いほど、その値が大きい。これは、上述したＪＩ
Ｔｅｄコード破棄方針をよく模倣する点で優れている。
先ほどの例でいえば、仮にＡがスタック上位、Ｂがスタ
ック下位からそれぞれ呼ばれるメソッドであれば、本発
明のアルゴリズムによってＡの活動度はＢの活動度より
高くなり、Ｂより先にＡを選んで破棄することはなくな
る。
【００１６】あるスレッドでＪＩＴコンパイラのメモリ
要求が満たせなくなったとき、そのメソッドは自分以外
のスレッドをすべて一時停止し、アクティブメソッドを
見つける。本発明によるメソッド活動度計算方法によ
り、各メソッドの活動度を決定する。その後、このよう
な活動度に基づいて、非アクティブなメソッドの一部あ
るいは全部のＪＩＴｅｄコードを破棄する。一時停止し
たスレッドをすべて再開し、メモリ要求を再度行なう。
これをメモリ要求が満たされるまで行なう。最終的にメ
モリ要求が満たされない場合、許されるなら、コンパイ
ラの最適化レベルを下げて再度コンパイルに挑戦する。
再度のコンパイルが許されない場合、あるいは最低の最
適化レベルでもコンパイルできなかった場合は、このメ
ソッドをコンパイルしない。
要求が満たせなくなったとき、そのメソッドは自分以外
のスレッドをすべて一時停止し、アクティブメソッドを
見つける。本発明によるメソッド活動度計算方法によ
り、各メソッドの活動度を決定する。その後、このよう
な活動度に基づいて、非アクティブなメソッドの一部あ
るいは全部のＪＩＴｅｄコードを破棄する。一時停止し
たスレッドをすべて再開し、メモリ要求を再度行なう。
これをメモリ要求が満たされるまで行なう。最終的にメ
モリ要求が満たされない場合、許されるなら、コンパイ
ラの最適化レベルを下げて再度コンパイルに挑戦する。
再度のコンパイルが許されない場合、あるいは最低の最
適化レベルでもコンパイルできなかった場合は、このメ
ソッドをコンパイルしない。
【００１７】メソッド活動度を計算するための作業コス
トを低減するために、メソッドの活動度を、これらがさ
らに呼び出すメソッドの活動度に作用させる動作の回数
に上限を設けてもよい。
トを低減するために、メソッドの活動度を、これらがさ
らに呼び出すメソッドの活動度に作用させる動作の回数
に上限を設けてもよい。
【００１８】
【発明の実施の形態】本発明は、ＪＩＴｅｄコード破棄
方針を模倣するために、メソッドに活動度と呼ばれる優
先順位を与える方法である。ＪＩＴｅｄコード破棄方針
とは、「しばらく呼ばれそうにない順にＪＩＴｅｄコー
ドを破棄する」ことである。低い活動度のメソッドほ
ど、しばらく呼ばれないと予想できる。しばらく呼ばれ
ないメソッドのＪＩＴｅｄコードを破棄すれば、それら
によって使われていたメモリ量のフリーメモリは長い間
活用できるはずである。
方針を模倣するために、メソッドに活動度と呼ばれる優
先順位を与える方法である。ＪＩＴｅｄコード破棄方針
とは、「しばらく呼ばれそうにない順にＪＩＴｅｄコー
ドを破棄する」ことである。低い活動度のメソッドほ
ど、しばらく呼ばれないと予想できる。しばらく呼ばれ
ないメソッドのＪＩＴｅｄコードを破棄すれば、それら
によって使われていたメモリ量のフリーメモリは長い間
活用できるはずである。
【００１９】以下、メソッドｍの活動度Ａ（ｍ）の計算
手順を示す。各メソッドの活動度の初期値を０とする。
まず、ＪＩＴコンパイラによるコンパイルおよび実行時
における動作を、図２のフローチャートを参照して説明
する。ステップＳ２０１で開始し、ステップＳ２０２
で、メソッドｍに関して、ＪＩＴｅｄコード中のアドレ
スａｄｄｒと、このアドレスからメソッドの実行が再開
したときに呼ばれる（あるいは可能性がある）メソッド
集合とを対応させるための、アドレス−呼び出しマップ
ＭＡＰＡ−Ｉ（ｍ）を作る。アドレス−呼び出しマップ
は、ａｄｄｒを含む基本ブロックＢＢ（ｂａｓｉｃ ｂ
ｌｏｃｋ）と、このＢＢからコントロールフロー上で到
達する前記メソッド呼び出しとを対応づけるものであ
る。このアドレス−呼び出しマップは、あるアドレスａ
ｄｄｒが与えられたときに、このａｄｄｒから到達する
全メソッド呼び出しを返す。この全メソッド呼び出しを
呼び出し集合ＳＥＴＡ−Ｉ（ｍ，ａｄｄｒ）と呼ぶ。
手順を示す。各メソッドの活動度の初期値を０とする。
まず、ＪＩＴコンパイラによるコンパイルおよび実行時
における動作を、図２のフローチャートを参照して説明
する。ステップＳ２０１で開始し、ステップＳ２０２
で、メソッドｍに関して、ＪＩＴｅｄコード中のアドレ
スａｄｄｒと、このアドレスからメソッドの実行が再開
したときに呼ばれる（あるいは可能性がある）メソッド
集合とを対応させるための、アドレス−呼び出しマップ
ＭＡＰＡ−Ｉ（ｍ）を作る。アドレス−呼び出しマップ
は、ａｄｄｒを含む基本ブロックＢＢ（ｂａｓｉｃ ｂ
ｌｏｃｋ）と、このＢＢからコントロールフロー上で到
達する前記メソッド呼び出しとを対応づけるものであ
る。このアドレス−呼び出しマップは、あるアドレスａ
ｄｄｒが与えられたときに、このａｄｄｒから到達する
全メソッド呼び出しを返す。この全メソッド呼び出しを
呼び出し集合ＳＥＴＡ−Ｉ（ｍ，ａｄｄｒ）と呼ぶ。
【００２０】アドレス−呼び出しマップの計算をするた
めには、コントロールフローを解析し、基本ブロックＢ
Ｂ毎に、ＢＢが到達する可能性のあるメソッド呼び出し
のアドレスを集める。それから、ＢＢの先頭アドレスi
＿addrとリーチされるメソッド呼び出しアドレスi ＿ca
llの関係データ（例えば、（i ＿addr, i ＿call）をソ
ートした表）をコンパイルコードにつける。呼び出し集
合は、ａｄｄｒを含むＢＢに対応するすべてのi ＿call
である。図３は、メソッドＥのＪＩＴｅｄコードを示す
線図である。メソッドＥは、ＢＢ１ないしＢＢ５から成
る。この図において、アドレス１１５において、メソッ
ドＦを呼び出している。したがって、呼び出し集合は、
ａｄｄｒ＝１００〜１１５はＦを返し、ａｄｄｒ＝１１
６〜１２０は何も返さない。
めには、コントロールフローを解析し、基本ブロックＢ
Ｂ毎に、ＢＢが到達する可能性のあるメソッド呼び出し
のアドレスを集める。それから、ＢＢの先頭アドレスi
＿addrとリーチされるメソッド呼び出しアドレスi ＿ca
llの関係データ（例えば、（i ＿addr, i ＿call）をソ
ートした表）をコンパイルコードにつける。呼び出し集
合は、ａｄｄｒを含むＢＢに対応するすべてのi ＿call
である。図３は、メソッドＥのＪＩＴｅｄコードを示す
線図である。メソッドＥは、ＢＢ１ないしＢＢ５から成
る。この図において、アドレス１１５において、メソッ
ドＦを呼び出している。したがって、呼び出し集合は、
ａｄｄｒ＝１００〜１１５はＦを返し、ａｄｄｒ＝１１
６〜１２０は何も返さない。
【００２１】アドレス−呼び出しマップの計算コストを
大幅に削減するには、正確でないが、メソッドｍのアド
レス−呼び出しマップを、ｍに含まれるすべてのメソッ
ド呼び出しの集合としてもよい。このとき呼び出し集合
もｍに含まれるすべてのメソッド呼び出しの集合であ
る。
大幅に削減するには、正確でないが、メソッドｍのアド
レス−呼び出しマップを、ｍに含まれるすべてのメソッ
ド呼び出しの集合としてもよい。このとき呼び出し集合
もｍに含まれるすべてのメソッド呼び出しの集合であ
る。
【００２２】ＪＩＴｅｄコード中にあるメソッド呼び出
しのためのｃａｌｌ命令は、最適化のために、なるべく
ダイレクトコール（direct call ）になるように処理さ
れる。例えば、あるメソッド呼び出しをコンパイルする
際に呼び出し先のメソッドがまだコンパイルされていな
い場合、コンパイラはダイレクトコール命令を生成でき
ない。このようなメソッド呼び出しが発生すると、バッ
クパッチコードにジャンプして、ＪＩＴコンパイラによ
って生成されたターゲットアドレスを次回のメソッド呼
び出しから用いることができるように設定する。このよ
うな処理は従来から行われてきた。本発明では、メソッ
ド呼び出しを最初に行う場合には、ターゲットアドレス
がまだ生成されていない場合でも生成されている場合で
も必ず、バックパッチコードにジャンプし、ターゲット
アドレスを記録するようにする（Ｓ２０３のコードを用
いる）。２回目以降のメソッド呼び出しでは、バックパ
ッチコードにジャンプする必要はない。
しのためのｃａｌｌ命令は、最適化のために、なるべく
ダイレクトコール（direct call ）になるように処理さ
れる。例えば、あるメソッド呼び出しをコンパイルする
際に呼び出し先のメソッドがまだコンパイルされていな
い場合、コンパイラはダイレクトコール命令を生成でき
ない。このようなメソッド呼び出しが発生すると、バッ
クパッチコードにジャンプして、ＪＩＴコンパイラによ
って生成されたターゲットアドレスを次回のメソッド呼
び出しから用いることができるように設定する。このよ
うな処理は従来から行われてきた。本発明では、メソッ
ド呼び出しを最初に行う場合には、ターゲットアドレス
がまだ生成されていない場合でも生成されている場合で
も必ず、バックパッチコードにジャンプし、ターゲット
アドレスを記録するようにする（Ｓ２０３のコードを用
いる）。２回目以降のメソッド呼び出しでは、バックパ
ッチコードにジャンプする必要はない。
【００２３】ステップＳ２０３で、メソッド呼び出しの
バックパッチコード中に、各呼び出しコードによって実
際に呼び出しが起きたことを記録するコードを生成す
る。この記録を有効呼び出し集合ＳＥＴＥＩ（ｍ）と呼
ぶ。この有効呼び出し集合は、呼び出しアドレスとター
ゲットアドレスのペア（ei＿call,ei ＿target）の集合
である。ei＿targetの初期値はＮＵＬＬである。ei＿ta
rgetがＮＵＬＬでない要素が意味のある要素である。
バックパッチコード中に、各呼び出しコードによって実
際に呼び出しが起きたことを記録するコードを生成す
る。この記録を有効呼び出し集合ＳＥＴＥＩ（ｍ）と呼
ぶ。この有効呼び出し集合は、呼び出しアドレスとター
ゲットアドレスのペア（ei＿call,ei ＿target）の集合
である。ei＿targetの初期値はＮＵＬＬである。ei＿ta
rgetがＮＵＬＬでない要素が意味のある要素である。
【００２４】ステップＳ２０４で、コンパイラは、メソ
ッドをコンパイルする際に、全てのターゲットアドレス
についての表（ei＿call，ei＿target）を作り、コンパ
イルコードに付ける。例えば、表１のようなものであ
る。
ッドをコンパイルする際に、全てのターゲットアドレス
についての表（ei＿call，ei＿target）を作り、コンパ
イルコードに付ける。例えば、表１のようなものであ
る。
【表１】 この表が有効呼び出し集合となる。コンパイル時の処理
は以上である。
は以上である。
【００２５】ＪＩＴｅｄコードが実行され、Ｓ２０３で
生成されたコードが実行されると、呼び出しを行なった
メソッドの有効呼び出し集合の対応するエントリ（ei＿
call，ei＿target）のei＿targetが更新される。ここ
で、有効呼び出し集合においてei＿targetに実際のター
ゲットアドレスが入っている呼び出しのみが、実際に呼
び出しを行なう有効呼び出しである。ステップＳ２０６
で処理を終了する。なお、表１は、例えば表２のように
なる。
生成されたコードが実行されると、呼び出しを行なった
メソッドの有効呼び出し集合の対応するエントリ（ei＿
call，ei＿target）のei＿targetが更新される。ここ
で、有効呼び出し集合においてei＿targetに実際のター
ゲットアドレスが入っている呼び出しのみが、実際に呼
び出しを行なう有効呼び出しである。ステップＳ２０６
で処理を終了する。なお、表１は、例えば表２のように
なる。
【表２】
【００２６】次に、ＪＩＴｅｄコードの回収プロセス中
（全スレッドは一時停止状態）にメソッドの活動度を決
定する。以下、図４のフローチャートを参照して説明す
る。
（全スレッドは一時停止状態）にメソッドの活動度を決
定する。以下、図４のフローチャートを参照して説明す
る。
【００２７】ステップＳ４０１でコンパイル中にメモリ
の制限に達すると、ステップ４０２でＪＩＴコンパイラ
は動作中のスレッドを一時停止する。
の制限に達すると、ステップ４０２でＪＩＴコンパイラ
は動作中のスレッドを一時停止する。
【００２８】ステップＳ４０３で、各スレッドにおい
て、ＪＩＴｅｄコードのフレームをスタック天井から底
へ向けて検索する。見つかったＪＩＴｅｄコードに対応
するメソッドをアクティブメソッドｍ０と呼ぶ。
て、ＪＩＴｅｄコードのフレームをスタック天井から底
へ向けて検索する。見つかったＪＩＴｅｄコードに対応
するメソッドをアクティブメソッドｍ０と呼ぶ。
【００２９】ステップＳ４０４で、アクティブメソッド
ｍ０に優先度付けする。最も天井に近いメソッドから底
へ向けてｉ番め（ｉ＞＝０）のメソッドの優先度をｗ
（ｉ）とする。ここで、ｗ（ｉ）＞ｗ（ｉ＋１）とす
る。例えば、ｗ（ｉ）＝０．９ｉとする。
ｍ０に優先度付けする。最も天井に近いメソッドから底
へ向けてｉ番め（ｉ＞＝０）のメソッドの優先度をｗ
（ｉ）とする。ここで、ｗ（ｉ）＞ｗ（ｉ＋１）とす
る。例えば、ｗ（ｉ）＝０．９ｉとする。
【００３０】ステップＳ４０５で、各アクティブメソッ
ドｍ０に対して、その停止アドレスａｄｄｒ（まさにそ
のメソッドで一時停止されたならそのコンテキストのプ
ログラムカウンタの値（ｐｃ）、それ以外ならフレーム
に保存された次のｐｃ）を用いて、アドレス−呼び出し
マップＭＡＰA-I （ｍ0 ）を引いて、呼び出し集合ＳＥ
ＴA-I （ｍ0 ，ａｄｄｒ）を得る。
ドｍ０に対して、その停止アドレスａｄｄｒ（まさにそ
のメソッドで一時停止されたならそのコンテキストのプ
ログラムカウンタの値（ｐｃ）、それ以外ならフレーム
に保存された次のｐｃ）を用いて、アドレス−呼び出し
マップＭＡＰA-I （ｍ0 ）を引いて、呼び出し集合ＳＥ
ＴA-I （ｍ0 ，ａｄｄｒ）を得る。
【００３１】ステップＳ４０６で、さらにメソッドｍ０
の有効呼び出し集合ＳＥＴEI（ｍ0）を参照して、ステ
ップＳ４０７で、ＳＥＴA-EI（ｍ0 ，ａｄｄｒ）を得
る。ＳＥＴA-EI（ｍ0 ，ａｄｄｒ）は、ｍ0 のａｄｄｒ
から実行が再開したときに、ｍ 0 から実際に実行される
可能性があるメソッド呼び出しと、このメソッド呼び出
しによって呼ばれるターゲットメソッドｍ1 のアドレス
の集合である。ＳＥＴA- EIはメモリに格納される。
の有効呼び出し集合ＳＥＴEI（ｍ0）を参照して、ステ
ップＳ４０７で、ＳＥＴA-EI（ｍ0 ，ａｄｄｒ）を得
る。ＳＥＴA-EI（ｍ0 ，ａｄｄｒ）は、ｍ0 のａｄｄｒ
から実行が再開したときに、ｍ 0 から実際に実行される
可能性があるメソッド呼び出しと、このメソッド呼び出
しによって呼ばれるターゲットメソッドｍ1 のアドレス
の集合である。ＳＥＴA- EIはメモリに格納される。
【００３２】Ｓ４０８で、ＳＥＴA-EI（ｍ0 ，ａｄｄ
ｒ）に含まれるすべてのターゲットメソッドｍ1 に対し
て、ｍ0 の優先度ｗ（ｉ）を活動度Ａ（ｍ1 ）に作用
（例：加算）させる。これをＵｐｄａｔｅＡ（ｍ1 ，ｗ
（ｉ））と書く。
ｒ）に含まれるすべてのターゲットメソッドｍ1 に対し
て、ｍ0 の優先度ｗ（ｉ）を活動度Ａ（ｍ1 ）に作用
（例：加算）させる。これをＵｐｄａｔｅＡ（ｍ1 ，ｗ
（ｉ））と書く。
【００３３】同様に、ｍ1 が呼ばれたとき、ｍ1 が呼ぶ
可能性の高いターゲットメソッドｍ２の集合を有効呼び
出し集合ＳＥＴＥＩ（ｍ1 ）で与える。そしてさらに、
ＳＥＴＥＩ（ｍ1 ）に属するすべてのターゲットメソッ
ドｍ2 に対しても、ＵｐｄａｔｅＡ（ｍ2 、ｗ（ｉ））
を行なう。以下同様にして、以降のターゲットメソッド
に対して、ＵｐｄａｔｅＡ（ｍ，ｗ（ｉ））を、全メソ
ッドに対して行われるまで繰り返す。すなわち、Ｓ４０
８の後に全メソッドに対してＵｐｄａｔｅＡ（ｍ，ｗ
（ｉ））を行なうまで、または所定数繰り返すまで、Ｓ
４０５乃至Ｓ４０８を繰り返す。
可能性の高いターゲットメソッドｍ２の集合を有効呼び
出し集合ＳＥＴＥＩ（ｍ1 ）で与える。そしてさらに、
ＳＥＴＥＩ（ｍ1 ）に属するすべてのターゲットメソッ
ドｍ2 に対しても、ＵｐｄａｔｅＡ（ｍ2 、ｗ（ｉ））
を行なう。以下同様にして、以降のターゲットメソッド
に対して、ＵｐｄａｔｅＡ（ｍ，ｗ（ｉ））を、全メソ
ッドに対して行われるまで繰り返す。すなわち、Ｓ４０
８の後に全メソッドに対してＵｐｄａｔｅＡ（ｍ，ｗ
（ｉ））を行なうまで、または所定数繰り返すまで、Ｓ
４０５乃至Ｓ４０８を繰り返す。
【００３４】図５は、ターゲットメソッドへの活動度の
割り当てを説明する線図である。このスレッドのスタッ
クの各アクティブメソッドｍ０には、スタック天井から
下向きに順番に、１、０．９、０．８１の優先度ｗが割
り当てられている。これらのアクティブメソッドが直接
呼び出すメソッドｍ１の活動度には、ｍ０の優先度ｗが
反映されている。さらに、ｍ１が呼び出すｍ２の活動度
には、ｍ１の活動度（優先度）が反映されている。但
し、２以上のメソッドから活動度が伝播されてくる場合
には、図５に示すように、保持している値と比較して、
大きな値の方を保持するようにすることも可能である。
また、図５の右にメソッドをたどるごとに活動度を低く
することも考えられる。さらに、ＵｐｄａｔｅＡ（ｍ，
ｗ（ｉ））でなく、ＵｐｄａｔｅＡ（ｍx ，ｍx-1 ）の
ような更新処理を定義することも可能である。
割り当てを説明する線図である。このスレッドのスタッ
クの各アクティブメソッドｍ０には、スタック天井から
下向きに順番に、１、０．９、０．８１の優先度ｗが割
り当てられている。これらのアクティブメソッドが直接
呼び出すメソッドｍ１の活動度には、ｍ０の優先度ｗが
反映されている。さらに、ｍ１が呼び出すｍ２の活動度
には、ｍ１の活動度（優先度）が反映されている。但
し、２以上のメソッドから活動度が伝播されてくる場合
には、図５に示すように、保持している値と比較して、
大きな値の方を保持するようにすることも可能である。
また、図５の右にメソッドをたどるごとに活動度を低く
することも考えられる。さらに、ＵｐｄａｔｅＡ（ｍ，
ｗ（ｉ））でなく、ＵｐｄａｔｅＡ（ｍx ，ｍx-1 ）の
ような更新処理を定義することも可能である。
【００３５】以上で、全メソッドに活動度が割り振られ
た。ＪＩＴコンパイラは、メソッド活動度の低いものか
ら順に、ＪＩＴｅｄコードを破棄し、スレッド実行を再
開して、コンパイルを継続する。
た。ＪＩＴコンパイラは、メソッド活動度の低いものか
ら順に、ＪＩＴｅｄコードを破棄し、スレッド実行を再
開して、コンパイルを継続する。
【００３６】この作業コストが問題になる場合、各スレ
ッドにおける優先度の更新回数（ＵｐｄａｔｅＡ（ｍ，
ｗ（ｉ））の実行回数）の上限を設けてもよい。
ッドにおける優先度の更新回数（ＵｐｄａｔｅＡ（ｍ，
ｗ（ｉ））の実行回数）の上限を設けてもよい。
【００３７】また、シンクロナイズド（synchronized）
メソッドでブロックしているスレッドについて、あるい
は低い優先度のスレッドについて、９においてスレッド
実行が再開してもしばらくはディスパッチされないと考
え、活動度の収集を行わなくてもよい。
メソッドでブロックしているスレッドについて、あるい
は低い優先度のスレッドについて、９においてスレッド
実行が再開してもしばらくはディスパッチされないと考
え、活動度の収集を行わなくてもよい。
【００３８】以上本発明の処理の流れを説明したが、本
発明はこれらの処理を実施する装置や、コンピュータに
これらの処理を実施させるプログラムの形態によっても
実現可能である。このプログラムを、フロッピー（登録
商標）・ディスクやＣＤ−ＲＯＭ等の記憶媒体又は他の
形態の記憶装置に格納することは、通常当業者が行う事
項である。
発明はこれらの処理を実施する装置や、コンピュータに
これらの処理を実施させるプログラムの形態によっても
実現可能である。このプログラムを、フロッピー（登録
商標）・ディスクやＣＤ−ＲＯＭ等の記憶媒体又は他の
形態の記憶装置に格納することは、通常当業者が行う事
項である。
【００３９】ここで本発明に関連する装置構成の一例を
図６を用いて説明しておく。サーバ・コンピュータ１及
びクライアント・コンピュータ５はネットワーク３を介
して接続されている。クライアント・コンピュータ５
は、ＪａｖａＶＭ（Virtual Machine ）５２及びＯＳ
（Operating System）５３及びハードウエア（ＣＰＵ及
びメモリを含む）５５を含む。さらに、ＪａｖａＶＭ５
２は、Ｊａｖａインタープリタ５４及びＪａｖａ ＪＩ
Ｔコンパイラ５６を含む。ＪａｖａＶＭ５２は、図示し
ないガベージコレクタやスタックトレーサをさらに含
む。なお、クライアント・コンピュータ５は、通常のコ
ンピュータの他、メモリの大きさが小さかったり、ハー
ドディスク等の補助記憶装置を含まないような、いわゆ
るネットワーク・コンピュータや情報家電の場合もあ
る。
図６を用いて説明しておく。サーバ・コンピュータ１及
びクライアント・コンピュータ５はネットワーク３を介
して接続されている。クライアント・コンピュータ５
は、ＪａｖａＶＭ（Virtual Machine ）５２及びＯＳ
（Operating System）５３及びハードウエア（ＣＰＵ及
びメモリを含む）５５を含む。さらに、ＪａｖａＶＭ５
２は、Ｊａｖａインタープリタ５４及びＪａｖａ ＪＩ
Ｔコンパイラ５６を含む。ＪａｖａＶＭ５２は、図示し
ないガベージコレクタやスタックトレーサをさらに含
む。なお、クライアント・コンピュータ５は、通常のコ
ンピュータの他、メモリの大きさが小さかったり、ハー
ドディスク等の補助記憶装置を含まないような、いわゆ
るネットワーク・コンピュータや情報家電の場合もあ
る。
【００４０】サーバ・コンピュータ１では、Ｊａｖａソ
ースコード１０は、Ｊａｖａコンパイラ１２によりコン
パイルされる。このコンパイルの結果が、バイトコード
１４である。このバイトコード１４は、ネットワーク３
を介してクライアント・コンピュータ５に送信される。
バイトコード１４は、クライアント・コンピュータ５内
のＷＷＷブラウザ（World Wide Web Browser）などに設
けられたＪａｖａ仮想マシン（Java VM ）５２にとって
ネイティブ・コードであり、実際ハードウエア５５のＣ
ＰＵにて実行する場合には、Ｊａｖａインタープリタ５
４や、ＪａｖａＪＩＴコンパイラ５６を用いる。インタ
ープリタ５４は、実行時にバイトコード１４をデコード
し、命令ごとに用意される処理ルーチンを呼び出して実
行する。一方、ＪＩＴコンパイラ５６は、バイトコード
を事前にあるいは実行する直前にコンパイラを用いてマ
シン・コード５８に変換してそれをＣＰＵで実行する。
ースコード１０は、Ｊａｖａコンパイラ１２によりコン
パイルされる。このコンパイルの結果が、バイトコード
１４である。このバイトコード１４は、ネットワーク３
を介してクライアント・コンピュータ５に送信される。
バイトコード１４は、クライアント・コンピュータ５内
のＷＷＷブラウザ（World Wide Web Browser）などに設
けられたＪａｖａ仮想マシン（Java VM ）５２にとって
ネイティブ・コードであり、実際ハードウエア５５のＣ
ＰＵにて実行する場合には、Ｊａｖａインタープリタ５
４や、ＪａｖａＪＩＴコンパイラ５６を用いる。インタ
ープリタ５４は、実行時にバイトコード１４をデコード
し、命令ごとに用意される処理ルーチンを呼び出して実
行する。一方、ＪＩＴコンパイラ５６は、バイトコード
を事前にあるいは実行する直前にコンパイラを用いてマ
シン・コード５８に変換してそれをＣＰＵで実行する。
【００４１】
【発明の効果】本発明によれば、コード破棄するメソッ
ドを効果的に選択することができるため、同一メソッド
の再コンパイル回数が減少し、コンパイルオーバヘッド
を減少させることができる。
ドを効果的に選択することができるため、同一メソッド
の再コンパイル回数が減少し、コンパイルオーバヘッド
を減少させることができる。
【図面の簡単な説明】
【図１】 サブルーチンＡがサブルーチンＢを、サブル
ーチンＢがサブルーチンＣを呼び出したときのスタック
を示す線図である。
ーチンＢがサブルーチンＣを呼び出したときのスタック
を示す線図である。
【図２】 本発明によるメソッド活動度計算方法のＪＩ
Ｔコンパイルおよび実行時における動作を説明するフロ
ーチャートである。
Ｔコンパイルおよび実行時における動作を説明するフロ
ーチャートである。
【図３】 メソッドＥのＪＩＴｅｄコードを示す線図で
ある
ある
【図４】 本発明によるメソッド活動度計算方法のＪＩ
Ｔｅｄコードの回収プロセス中における動作を説明する
フローチャートである。
Ｔｅｄコードの回収プロセス中における動作を説明する
フローチャートである。
【図５】 ターゲットメソッドへの活動度の割り当てを
説明する線図である。
説明する線図である。
【図６】 本発明における装置構成の一例を示す図であ
る。
る。
１ サーバ・コンピュータ ３ ネットワーク ５ クライアント・コンピュータ １０ Ｊａｖａソースコード １２ Ｊａｖａコンパイラ １４ バイトコード ５２ ＪａｖａＶＭ ５４ Ｊａｖａインタプリタ ５６ Ｊａｖａ ＪＩＴコンパイラ ５８ マシンコード ６０ ガベージ・コレクタ ５３ ＯＳ ５５ ハードウエア（ＣＰＵ及びメモリを含む）
───────────────────────────────────────────────────── フロントページの続き (72)発明者 小笠原 武史 神奈川県大和市下鶴間1623番地14 日本ア イ・ビー・エム株式会社 東京基礎研究所 内 Ｆターム(参考） 5B033 DE07 5B042 MC23 MC28 5B081 CC00
Claims (9)
- 【請求項１】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップを作成し且つ記憶装置に格納
し、実際に生じたメソッド呼び出しを記録するコードを
生成し且つ記憶装置に格納するコンパイル方法。 - 【請求項２】 前記呼び出しマップが、前記メソッド中
のあるアドレスに対し、当該あるアドレス以降に生じ得
るメソッド呼び出しを出力する請求項１記載のコンパイ
ル方法。 - 【請求項３】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップと実際に生じたメソッド呼び出
しに関する情報とが各メソッドごとに記録されている場
合に、あるメソッドが実行される可能性の高低を表す活
動度を計算する方法であって、 スタックフレームに対応する第１メソッドについての、
前記呼び出しマップと実際に生じたメソッド呼び出しに
関する情報とを用いて、前記第１メソッドから呼ばれる
可能性が高い第２メソッドを特定し且つ記憶装置に格納
し、前記第１メソッドに対応するスタックフレームのス
タックの最上部からの段数に応じた優先度を前記第２メ
ソッドの活動度に作用することにより前記第２メソッド
の活動度を更新するメソッド活動度計算方法。 - 【請求項４】 前記第２メソッドについての、前記呼び
出しマップと実際に生じたメソッド呼び出しに関する情
報と用いて、前記第２メソッドから呼ばれる可能性が高
い第３メソッドを特定し且つ記憶装置に格納し、前記第
１メソッドに対応するスタックフレームのスタックの最
上部からの段数に応じた優先度を前記第３メソッドの活
動度に作用することにより前記第３メソッドの活動度を
更新する請求項３記載のメソッド活動度計算方法。 - 【請求項５】 前記呼び出しマップが、前記メソッド中
のあるアドレスに対し、当該アドレス以降に生じ得るメ
ソッド呼び出しを出力するように構成され、前記第２メ
ソッドの特定は、前記第１メソッドの実行再開アドレス
以降に生じ得るメソッド呼び出しを用いて行われる請求
項３記載のメソッド活動度計算方法。 - 【請求項６】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップを作成し且つ記憶装置に格納す
る手段と、実際に生じたメソッド呼び出しを記録するコ
ードを生成し且つ記憶装置に格納する手段とを有するコ
ンパイル装置。 - 【請求項７】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップと実際に生じたメソッド呼び出
しに関する情報とが各メソッドごとに記録されている場
合に、あるメソッドが実行される可能性の高低を表す活
動度を計算する装置であって、 スタックフレームに対応する第１メソッドについての、
前記呼び出しマップと実際に生じたメソッド呼び出しに
関する情報とを用いて、前記第１メソッドから呼ばれる
可能性が高い第２メソッドを特定し且つ記憶装置に格納
する手段と、前記第１メソッドに対応するスタックフレ
ームのスタックの最上部からの段数に応じた優先度を前
記第２メソッドの活動度に作用することにより前記第２
メソッドの活動度を更新する手段とを有するメソッド活
動度計算装置。 - 【請求項８】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップを作成し且つ記憶装置に格納す
るステップと、実際に生じたメソッド呼び出しを記録す
るコードを生成し且つ記憶装置に格納するステップとを
コンピュータに実行させるコンパイラを格納した記憶媒
体。 - 【請求項９】 メソッド中で生じ得るメソッド呼び出し
に関する呼び出しマップと実際に生じたメソッド呼び出
しに関する情報とが各メソッドごとに記録されている場
合に、あるメソッドが実行される可能性の高低を表す活
動度を計算するためのプログラムを格納した記憶媒体で
あって、前記プログラムは、 スタックフレームに対応する第１メソッドについての、
前記呼び出しマップと実際に生じたメソッド呼び出しに
関する情報とを用いて、前記第１メソッドから呼ばれる
可能性が高い第２メソッドを特定し且つ記憶装置に格納
する機能と、前記第１メソッドに対応するスタックフレ
ームのスタックの最上部からの段数に応じた優先度を前
記第２メソッドの活動度に作用することにより前記第２
メソッドの活動度を更新する機能とを実現するためのも
のである、記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02203099A JP3807860B2 (ja) | 1999-01-29 | 1999-01-29 | コンパイル方法および装置、並びにメソッド活動度計算方法および装置 |
| US09/493,768 US6671877B1 (en) | 1999-01-29 | 2000-01-28 | Method and device to calculate activity degrees of method programs |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02203099A JP3807860B2 (ja) | 1999-01-29 | 1999-01-29 | コンパイル方法および装置、並びにメソッド活動度計算方法および装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000222221A true JP2000222221A (ja) | 2000-08-11 |
| JP3807860B2 JP3807860B2 (ja) | 2006-08-09 |
Family
ID=12071593
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02203099A Expired - Fee Related JP3807860B2 (ja) | 1999-01-29 | 1999-01-29 | コンパイル方法および装置、並びにメソッド活動度計算方法および装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6671877B1 (ja) |
| JP (1) | JP3807860B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007272576A (ja) * | 2006-03-31 | 2007-10-18 | Hitachi Ltd | サーバ装置及び仮想計算機の制御プログラム |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7350200B2 (en) * | 2001-03-29 | 2008-03-25 | Intel Corporation | Method and system of controlling dynamically compiled native code size |
| US7313789B1 (en) * | 2004-02-27 | 2007-12-25 | Sun Microsystems, Inc. | Methods and systems for reducing a program size |
| US7568190B2 (en) * | 2005-03-08 | 2009-07-28 | International Business Machines Corporation | Late binding of optimization information for just in time compilation |
| US9207921B2 (en) * | 2009-06-22 | 2015-12-08 | Oracle America, Inc. | Fault tolerant compilation with automatic optimization adjustment |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07210424A (ja) | 1994-01-14 | 1995-08-11 | Toshiba Corp | ソフトウェアテスト支援システム |
| US5933635A (en) * | 1997-10-06 | 1999-08-03 | Sun Microsystems, Inc. | Method and apparatus for dynamically deoptimizing compiled activations |
| US6105033A (en) * | 1997-12-29 | 2000-08-15 | Bull Hn Information Systems Inc. | Method and apparatus for detecting and removing obsolete cache entries for enhancing cache system operation |
| JP3199013B2 (ja) | 1998-01-26 | 2001-08-13 | 日本電気株式会社 | 言語処理方法及び言語処理装置並びに言語処理プログラムを記録した記憶媒体 |
| US6110226A (en) * | 1998-02-19 | 2000-08-29 | Cygnus Solutions | Java development environment using optimizing ahead-of-time compiler |
| EP0943990A3 (en) * | 1998-02-27 | 2004-12-22 | Texas Instruments Incorporated | Method and system of providing dynamic optimization information in a code interpretive runtime environment |
| US6226783B1 (en) * | 1998-03-16 | 2001-05-01 | Acuity Imaging, Llc | Object oriented method of structuring a software step program |
| US6507946B2 (en) * | 1999-06-11 | 2003-01-14 | International Business Machines Corporation | Process and system for Java virtual method invocation |
-
1999
- 1999-01-29 JP JP02203099A patent/JP3807860B2/ja not_active Expired - Fee Related
-
2000
- 2000-01-28 US US09/493,768 patent/US6671877B1/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007272576A (ja) * | 2006-03-31 | 2007-10-18 | Hitachi Ltd | サーバ装置及び仮想計算機の制御プログラム |
| US8104035B2 (en) | 2006-03-31 | 2012-01-24 | Hitachi, Ltd. | Program for controlling a virtual computer and computer system for virtulization technology |
Also Published As
| Publication number | Publication date |
|---|---|
| US6671877B1 (en) | 2003-12-30 |
| JP3807860B2 (ja) | 2006-08-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5139987B2 (ja) | 拡張可能メタデータ | |
| US9495136B2 (en) | Using aliasing information for dynamic binary optimization | |
| US7406684B2 (en) | Compiler, dynamic compiler, and replay compiler | |
| US6093216A (en) | Method of run-time tracking of object references in Java programs | |
| US8032899B2 (en) | Providing policy-based operating system services in a hypervisor on a computing system | |
| US8166470B2 (en) | Method for replacing code in a running object oriented program | |
| US8832672B2 (en) | Ensuring register availability for dynamic binary optimization | |
| JP3470948B2 (ja) | 動的コンパイル時期決定方法、バイトコード実行モード選択方法、及びコンピュータ | |
| KR100555116B1 (ko) | 객체-지향 시스템에서 수신기 타입을 위한 인-라인데이터베이스 | |
| JPH11272476A (ja) | バイトコードされたプログラムを動的に最適化するための方法及び装置 | |
| US11188364B1 (en) | Compilation strategy for a sharable application snapshot | |
| JPH11237990A (ja) | 混合実行スタックおよび例外処理 | |
| US20100131803A1 (en) | Computation of stack usage in embedded computing systems | |
| US7100154B2 (en) | Dynamic compiler apparatus and method that stores and uses persistent execution statistics | |
| US8429218B2 (en) | Process restart on a compute node | |
| US6735761B1 (en) | Compile method frame detection method and device code discarding method and computer | |
| JPH11338699A (ja) | プログラム処理方法、指定メソッドに関連するフレームの深さを検出する方法、検出方法、及びコンピュータ | |
| JP3807860B2 (ja) | コンパイル方法および装置、並びにメソッド活動度計算方法および装置 | |
| JP4088379B2 (ja) | コンパイル方法及び装置、並びにスタック・トレース方法及び装置 | |
| JP2000222219A (ja) | 多次元配列オブジェクトの処理方法及び装置 | |
| JP3280322B2 (ja) | コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ | |
| JP2003067206A (ja) | Ｌｐａｒシステムにおいて装置をダイナミックに割り当てるための方法 | |
| Noguchi et al. | Efficient global pointers with spontaneous process migration | |
| CN106547603B (zh) | 减少golang语言系统垃圾回收时间的方法和装置 | |
| Whaley | System checkpointing using reflection and program analysis |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20051102 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20051207 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20051212 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060411 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060516 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100526 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110526 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110526 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120526 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130526 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140526 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |