JP3280322B2 - コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ - Google Patents
コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータInfo
- Publication number
- JP3280322B2 JP3280322B2 JP26784298A JP26784298A JP3280322B2 JP 3280322 B2 JP3280322 B2 JP 3280322B2 JP 26784298 A JP26784298 A JP 26784298A JP 26784298 A JP26784298 A JP 26784298A JP 3280322 B2 JP3280322 B2 JP 3280322B2
- Authority
- JP
- Japan
- Prior art keywords
- routine
- stack
- stack frame
- code
- compiled
- 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.)
- Expired - Fee Related
Links
Description
【０００１】
【発明の属する技術分野】本発明は、コンパイラに関
し、より詳しくは、Java（Sun Microsystems社の商標）
のＪＩＴ（Just In Time）コンパイラに関する。
し、より詳しくは、Java（Sun Microsystems社の商標）
のＪＩＴ（Just In Time）コンパイラに関する。
【０００２】
【従来の技術】現在Javaがネットワーク・コンピューテ
ィングの共通言語としてだけでなく、プラットフォーム
に依存しない、オブジェクト指向言語のスタンダードな
言語という位置付けとなっている。Javaで書かれたプロ
グラムはバイトコードに変換され、バイトコードはJava
仮想マシンで実行される。そのため一度Javaで書かれた
プログラムは、Javaをサポートしているコンピュータな
らばＣＰＵを問わずどこでも動く（マルチプラットフォ
ーム）利点を持つ。
ィングの共通言語としてだけでなく、プラットフォーム
に依存しない、オブジェクト指向言語のスタンダードな
言語という位置付けとなっている。Javaで書かれたプロ
グラムはバイトコードに変換され、バイトコードはJava
仮想マシンで実行される。そのため一度Javaで書かれた
プログラムは、Javaをサポートしているコンピュータな
らばＣＰＵを問わずどこでも動く（マルチプラットフォ
ーム）利点を持つ。
【０００３】しかしこうした利点の反面、バイトコード
の仮想マシンによる実行は、機械語のコードを直接実行
するのに比べて、実行性能の点で劣る。そのため、ＪＩ
ＴコンパイラによりJavaプログラムの動作中にバイトコ
ードを機械語コード（以下、JITedコードと呼ぶ）に変
換して、バイトコードの代わりにJITedコードを実行す
るのが一般的である。コンパイルの最小単位は、メソッ
ドと呼ばれるサブルーチンである。実行頻度の高いコー
ドを機械語に変換することにより、Javaバイトコードの
マルチプラットフォーム特性を残しつつ、機械語コード
の性能を引き出す。
の仮想マシンによる実行は、機械語のコードを直接実行
するのに比べて、実行性能の点で劣る。そのため、ＪＩ
ＴコンパイラによりJavaプログラムの動作中にバイトコ
ードを機械語コード（以下、JITedコードと呼ぶ）に変
換して、バイトコードの代わりにJITedコードを実行す
るのが一般的である。コンパイルの最小単位は、メソッ
ドと呼ばれるサブルーチンである。実行頻度の高いコー
ドを機械語に変換することにより、Javaバイトコードの
マルチプラットフォーム特性を残しつつ、機械語コード
の性能を引き出す。
【０００４】メソッドのJITedコードは、プログラムが
動作するＣＰＵに適したコードになっているという点
で、Ｃコンパイラなどが生成する最適化コードと同等で
ある。一般に現在普及しているＣＰＵでは、サブルーチ
ンが呼ばれると、サブルーチンはスタック上に自分が使
用するローカル変数を格納するための領域（フレームと
呼ぶ）を形成する。図１は、サブルーチンＡがサブルー
チンＢを、サブルーチンＢがサブルーチンＣを呼び出し
たときのスタックの様子である。スタックは下から上へ
伸びる。各領域は、サブルーチンそれぞれのフレームを
表す。スタックポインタＳＰはフレームＣの最上部を指
している。サブルーチンＣがさらにサブルーチンＤを呼
べば、現在のＳＰから新たにサブルーチンＤのフレーム
が形成され、ＳＰはそのフレームの最上部を差し直す。
各サブルーチンから戻る際、フレームは除去される。サ
ブルーチンＤからサブルーチンＣへ戻る時、戻る前にサ
ブルーチンＤのフレームは除去され、ＳＰはサブルーチ
ンＣがサブルーチンＤを呼び出したときの値に戻る。Ja
vaではスレッドと呼ばれる実行単位毎にＣＰＵ資源が割
り振られ、１つのスレッドは固有のスタック（スレッド
・スタックと呼ぶ）を持つ。 JITedコードはスレッド・
スタック上に前述のようなフレーム（以下、JITedフレ
ームと呼ぶ）をつくる。
動作するＣＰＵに適したコードになっているという点
で、Ｃコンパイラなどが生成する最適化コードと同等で
ある。一般に現在普及しているＣＰＵでは、サブルーチ
ンが呼ばれると、サブルーチンはスタック上に自分が使
用するローカル変数を格納するための領域（フレームと
呼ぶ）を形成する。図１は、サブルーチンＡがサブルー
チンＢを、サブルーチンＢがサブルーチンＣを呼び出し
たときのスタックの様子である。スタックは下から上へ
伸びる。各領域は、サブルーチンそれぞれのフレームを
表す。スタックポインタＳＰはフレームＣの最上部を指
している。サブルーチンＣがさらにサブルーチンＤを呼
べば、現在のＳＰから新たにサブルーチンＤのフレーム
が形成され、ＳＰはそのフレームの最上部を差し直す。
各サブルーチンから戻る際、フレームは除去される。サ
ブルーチンＤからサブルーチンＣへ戻る時、戻る前にサ
ブルーチンＤのフレームは除去され、ＳＰはサブルーチ
ンＣがサブルーチンＤを呼び出したときの値に戻る。Ja
vaではスレッドと呼ばれる実行単位毎にＣＰＵ資源が割
り振られ、１つのスレッドは固有のスタック（スレッド
・スタックと呼ぶ）を持つ。 JITedコードはスレッド・
スタック上に前述のようなフレーム（以下、JITedフレ
ームと呼ぶ）をつくる。
【０００５】スレッド・スタック中にあるのは、JITed
フレームだけではない。JITedコードはJava仮想マシン
が提供する様々なサービスルーチンを呼び出す。サービ
スルーチンによっては、さらに新たなJava仮想マシンを
起動するものもある。図２はJITedコードとそれ以外の
コードのフレームがスレッドスタックで混じっていると
ころを表す。アルファベット文字がついている部分がJI
Tedフレームである。
フレームだけではない。JITedコードはJava仮想マシン
が提供する様々なサービスルーチンを呼び出す。サービ
スルーチンによっては、さらに新たなJava仮想マシンを
起動するものもある。図２はJITedコードとそれ以外の
コードのフレームがスレッドスタックで混じっていると
ころを表す。アルファベット文字がついている部分がJI
Tedフレームである。
【０００６】次に、ＪＩＴコンパイラが使用するメモリ
について考える。ＪＩＴコンパイラは、JITedコードの
保存あるいはコンパイル作業域のために、メモリを消費
する。しかし無限にメモリを使ってよいわけではない。
特にハードディスクを持たないコンピュータは、２次記
憶による仮想記憶がなく、実記憶だけなので、ＪＩＴコ
ンパイラに与えられるメモリ量に制限がある。実記憶の
みのコンピュータ普及の背景として、ＮＣ（Network Co
mputing）マシンの登場がある。ＮＣマシンは、サーバ
・クライアント環境におけるクライアント管理のコスト
削減の解決策として提案され、アプリケーション・プロ
グラムをサーバからダウンロードし、そのためハードデ
ィスクを持つ必要がなく低価格を達成できる。
について考える。ＪＩＴコンパイラは、JITedコードの
保存あるいはコンパイル作業域のために、メモリを消費
する。しかし無限にメモリを使ってよいわけではない。
特にハードディスクを持たないコンピュータは、２次記
憶による仮想記憶がなく、実記憶だけなので、ＪＩＴコ
ンパイラに与えられるメモリ量に制限がある。実記憶の
みのコンピュータ普及の背景として、ＮＣ（Network Co
mputing）マシンの登場がある。ＮＣマシンは、サーバ
・クライアント環境におけるクライアント管理のコスト
削減の解決策として提案され、アプリケーション・プロ
グラムをサーバからダウンロードし、そのためハードデ
ィスクを持つ必要がなく低価格を達成できる。
【０００７】ＪＩＴコンパイラが使用できるメモリに制
限が与えられたとき、メソッドのＪＩＴコンパイラ動作
中にメモリが足りなくなる状況が生じる。このときＪＩ
Ｔコンパイラは、(1)そのメソッドをコンパイルしな
い、あるいは(2)ＪＩＴコンパイラの最適化レベルを低
くしてよりメモリを消費しないコンパイルに切り替え
る、あるいは(3)新たな空きメモリを得る、の３通りが
考えられる。本発明では最後の場合を扱う。空きメモリ
を得るには、破棄可能な既存のJITedコードの一部ある
いは全てを破棄し、それらのコードで占めていた領域を
解放する。この概念自体はSmalltalkシステムの時代に
既に知られていたが、ＪＩＴコンパイラによる（Ｃ言語
並に）最適化されたフレームに対して適用可能な実現方
式は与えられていない。
限が与えられたとき、メソッドのＪＩＴコンパイラ動作
中にメモリが足りなくなる状況が生じる。このときＪＩ
Ｔコンパイラは、(1)そのメソッドをコンパイルしな
い、あるいは(2)ＪＩＴコンパイラの最適化レベルを低
くしてよりメモリを消費しないコンパイルに切り替え
る、あるいは(3)新たな空きメモリを得る、の３通りが
考えられる。本発明では最後の場合を扱う。空きメモリ
を得るには、破棄可能な既存のJITedコードの一部ある
いは全てを破棄し、それらのコードで占めていた領域を
解放する。この概念自体はSmalltalkシステムの時代に
既に知られていたが、ＪＩＴコンパイラによる（Ｃ言語
並に）最適化されたフレームに対して適用可能な実現方
式は与えられていない。
【０００８】破棄するのはJITedコードのみである。破
棄する作業全体をＪＩＴコード・ガベージコレクション
（ＧＣ）と呼ぶ。実行中のスレッドの現在のコンテキス
ト（プログラム・カウンタ（program counter）やスタ
ック・ポインタ（stack pointer）などＣＰＵ資源のコ
ピー）あるいはそのスレッド・スタック中に保持するJI
Tedコードのフレームには、そのスレッドでのアクティ
ブなメソッドが記録されている。アクティブなメソッド
のJITedコードが破棄されると、スレッドが実行できな
い。したがって、破棄するのは非アクティブのJITedコ
ードになる。手順としては、JITedコードを持つメソッ
ドは全て管理されているので、その中からアクティブな
メソッドを除外し、残りの非アクティブなメソッドのJI
Tedコードを破棄する。
棄する作業全体をＪＩＴコード・ガベージコレクション
（ＧＣ）と呼ぶ。実行中のスレッドの現在のコンテキス
ト（プログラム・カウンタ（program counter）やスタ
ック・ポインタ（stack pointer）などＣＰＵ資源のコ
ピー）あるいはそのスレッド・スタック中に保持するJI
Tedコードのフレームには、そのスレッドでのアクティ
ブなメソッドが記録されている。アクティブなメソッド
のJITedコードが破棄されると、スレッドが実行できな
い。したがって、破棄するのは非アクティブのJITedコ
ードになる。手順としては、JITedコードを持つメソッ
ドは全て管理されているので、その中からアクティブな
メソッドを除外し、残りの非アクティブなメソッドのJI
Tedコードを破棄する。
【０００９】問題はアクティブなメソッドの発見方法に
ある。別の言い方をすれば、スレッド・スタック中のJI
Tedフレームの発見方法が問題である。図２のように、
スレッド・スタック中にはJITedフレームとそれ以外の
フレームが混在している。
ある。別の言い方をすれば、スレッド・スタック中のJI
Tedフレームの発見方法が問題である。図２のように、
スレッド・スタック中にはJITedフレームとそれ以外の
フレームが混在している。
【００１０】発見効率は悪いものの、JITedコードの実
行性能にオーバーヘッドなしでJITedフレームを発見す
る方法に、コンサーバティブ・ガベージ・コレクション
（Conservative Garbage Collection）と同じ手法を用
いる方法（以下、保守的ＧＣ方式と呼ぶ）がある（図
３）。すなわち、スレッド・スタックの有効な領域をす
べてスキャンし、スレッド・スタックに保存されたすべ
ての値について、あるメソッドのJITedコードのアドレ
スかどうかを検討する。あるメソッドのJITedコードで
あれば、そのメソッドをアクティブなメソッドとする。
もしスレッド・スタック中にJITedフレーム（JITedコー
ドへのポインタを含む）が存在すれば、この保守的ＧＣ
方式で必ず発見される。しかし、この保守的ＧＣ方式に
は欠点がある。１つは偽のJITedコード・アドレスと、
もう１つは発見効率である。偽JITedコード・アドレス
問題は、保守的ＧＣ方式がスタック中の全ての値を対象
とするために、偶然JITedコードのアドレスが入ってい
れば、それを本当のJITedコードのアドレスと思わざる
を得ないことに起因する。発見効率の低さの原因は以下
のような事項を考慮すれば明らかである。実際のアプリ
ケーション・プログラムでは、しばしばスタック領域は
大きく、従ってあるメソッドのJITedコードのアドレス
かどうかを検討する回数が非常に多い。さらに、スキャ
ンで検討する任意の値から対応するメソッドを求めるコ
ストは軽くない。仮にJITedコードが割り当てられるメ
モリのアドレスでふるい分けしても、数千個、時には数
万個、動的に生成（あるいは消滅）するJITedコードに
対して、JITedコードアドレスからメソッドを求めるの
には検索コストがかかる。ＪＩＴコンパイラのコンパイ
ルが原因でプログラムが停止する期間はできるだけ小さ
くなければならない。
行性能にオーバーヘッドなしでJITedフレームを発見す
る方法に、コンサーバティブ・ガベージ・コレクション
（Conservative Garbage Collection）と同じ手法を用
いる方法（以下、保守的ＧＣ方式と呼ぶ）がある（図
３）。すなわち、スレッド・スタックの有効な領域をす
べてスキャンし、スレッド・スタックに保存されたすべ
ての値について、あるメソッドのJITedコードのアドレ
スかどうかを検討する。あるメソッドのJITedコードで
あれば、そのメソッドをアクティブなメソッドとする。
もしスレッド・スタック中にJITedフレーム（JITedコー
ドへのポインタを含む）が存在すれば、この保守的ＧＣ
方式で必ず発見される。しかし、この保守的ＧＣ方式に
は欠点がある。１つは偽のJITedコード・アドレスと、
もう１つは発見効率である。偽JITedコード・アドレス
問題は、保守的ＧＣ方式がスタック中の全ての値を対象
とするために、偶然JITedコードのアドレスが入ってい
れば、それを本当のJITedコードのアドレスと思わざる
を得ないことに起因する。発見効率の低さの原因は以下
のような事項を考慮すれば明らかである。実際のアプリ
ケーション・プログラムでは、しばしばスタック領域は
大きく、従ってあるメソッドのJITedコードのアドレス
かどうかを検討する回数が非常に多い。さらに、スキャ
ンで検討する任意の値から対応するメソッドを求めるコ
ストは軽くない。仮にJITedコードが割り当てられるメ
モリのアドレスでふるい分けしても、数千個、時には数
万個、動的に生成（あるいは消滅）するJITedコードに
対して、JITedコードアドレスからメソッドを求めるの
には検索コストがかかる。ＪＩＴコンパイラのコンパイ
ルが原因でプログラムが停止する期間はできるだけ小さ
くなければならない。
【００１１】
【発明が解決しようとする課題】本発明の目的は、ＪＩ
Ｔコンパイラの使用できるメモリは制限され、JITedフ
レームはＣコンパイラの最適化コードのフレーム並に最
適化され、且つスレッド・スタック上でJITedフレーム
とその他のフレームが混在する環境において、JITedフ
レームのみを検出出来るようすることである。
Ｔコンパイラの使用できるメモリは制限され、JITedフ
レームはＣコンパイラの最適化コードのフレーム並に最
適化され、且つスレッド・スタック上でJITedフレーム
とその他のフレームが混在する環境において、JITedフ
レームのみを検出出来るようすることである。
【００１２】また、JITedフレームを検出し、アクティ
ブなメソッドを発見することも目的である。
ブなメソッドを発見することも目的である。
【００１３】さらに、効率良く且つ高速に、JITedフレ
ームのみを検出できるようにすることも目的である。
ームのみを検出できるようにすることも目的である。
【００１４】さらに、破棄可能なメソッドのコードを検
出できるようにすることも目的である。
出できるようにすることも目的である。
【００１５】
【課題を解決するための手段】発見効率の視点から最も
効率の良い方法は、JITedフレームだけを管理する方法
（以下、JITedラストフレーム方式と呼ぶ）である（図
４）。□（以下、JITedラストフレームレコードと呼
ぶ）は連続するJITedフレームを管理し、それ自身リス
トを構成する。 JITedラストフレームレコードは、JITe
dコードがサービスルーチンなどの非JITedコードを呼ぶ
度に作成され、リストを更新する。しかし、このJITed
ラストフレーム方式には２つ欠点がある。１つは発見で
きないJITedフレームの可能性と、１つはJITedコードの
実行性能の悪化である。発見できないJITedフレームは
次のような場合に発生する。ＪＩＴコンパイラは性能向
上のために、Javaの例外を可能ならばＣＰＵ例外にマッ
ピングする。ここで、マッピングされたシステムで、
(1)ＣＰＵ例外（Javaの例外）が発生し、(2)その例外ハ
ンドラの実行中に、(3)別スレッドでＪＩＴコンパイラ
がメモリ不足によるJITコードＧＣを起こした、場合を
考える。この場合、例外を起こしたスレッドではJITed
コードの外のコードを実行しているにもかかわらず、最
新のJITedラストフレームレコード（図４では黒い□）
が構成されない。そのため発見されないJITedフレーム
ができてしまう（図４中ではメソッドＣとＤのJITedフ
レーム）。 実行性能の悪化については、JITedコードが
非JITedコードを呼ぶ度にJITedラストフレームレコード
を作成するため、JITedコードの実行性能は悪くなる。
以上の理由から、Java例外をＣＰＵ例外にマップし例外
処理中に他スレッドが動作するシステム、あるいは性能
を重視するシステムでは単純なJITedラストフレーム方
式は採用できない。
効率の良い方法は、JITedフレームだけを管理する方法
（以下、JITedラストフレーム方式と呼ぶ）である（図
４）。□（以下、JITedラストフレームレコードと呼
ぶ）は連続するJITedフレームを管理し、それ自身リス
トを構成する。 JITedラストフレームレコードは、JITe
dコードがサービスルーチンなどの非JITedコードを呼ぶ
度に作成され、リストを更新する。しかし、このJITed
ラストフレーム方式には２つ欠点がある。１つは発見で
きないJITedフレームの可能性と、１つはJITedコードの
実行性能の悪化である。発見できないJITedフレームは
次のような場合に発生する。ＪＩＴコンパイラは性能向
上のために、Javaの例外を可能ならばＣＰＵ例外にマッ
ピングする。ここで、マッピングされたシステムで、
(1)ＣＰＵ例外（Javaの例外）が発生し、(2)その例外ハ
ンドラの実行中に、(3)別スレッドでＪＩＴコンパイラ
がメモリ不足によるJITコードＧＣを起こした、場合を
考える。この場合、例外を起こしたスレッドではJITed
コードの外のコードを実行しているにもかかわらず、最
新のJITedラストフレームレコード（図４では黒い□）
が構成されない。そのため発見されないJITedフレーム
ができてしまう（図４中ではメソッドＣとＤのJITedフ
レーム）。 実行性能の悪化については、JITedコードが
非JITedコードを呼ぶ度にJITedラストフレームレコード
を作成するため、JITedコードの実行性能は悪くなる。
以上の理由から、Java例外をＣＰＵ例外にマップし例外
処理中に他スレッドが動作するシステム、あるいは性能
を重視するシステムでは単純なJITedラストフレーム方
式は採用できない。
【００１６】よって、JITedラストフレーム方式を基本
としながら、保守的ＧＣ方式を必要に応じて組み合わせ
たハイブリッドな方式を採用する。これにより、JITed
ラストフレーム方式の未発見JITedフレームと実行性能
悪化の２つの問題を解決すると同時に、保守的ＧＣ方式
を限定的に使用することによって発見効率低下を最小限
に押さえる。
としながら、保守的ＧＣ方式を必要に応じて組み合わせ
たハイブリッドな方式を採用する。これにより、JITed
ラストフレーム方式の未発見JITedフレームと実行性能
悪化の２つの問題を解決すると同時に、保守的ＧＣ方式
を限定的に使用することによって発見効率低下を最小限
に押さえる。
【００１７】まず、ＪＩＴコンパイラはJITedラストフ
レームレコードを構成する、JITedコード脱出ポイント
を検出する。このポイントには、例えば、頻繁に実行さ
れる非JITedコード呼び出しは原則として含まず、一度
だけ実行される非JITedコード呼び出しを含む。
レームレコードを構成する、JITedコード脱出ポイント
を検出する。このポイントには、例えば、頻繁に実行さ
れる非JITedコード呼び出しは原則として含まず、一度
だけ実行される非JITedコード呼び出しを含む。
【００１８】JITedラストフレームレコードは、非JITed
コードを呼ぶJITedコードのフレームを指す。また同時
に最後に作られたJITedラストフレームレコードも指
し、ＬＩＦＯ（Last In First Out）のリストを構成す
る（図５）。図５において□はJITedラストフレームレ
コードを表す。黒い□はメソッドＤが非JITedコードを
呼び出す前に作るJITedラストフレームレコードであ
る。JITedラストフレームレコード及びＬＩＦＯリスト
は、各スレッド毎に管理される。
コードを呼ぶJITedコードのフレームを指す。また同時
に最後に作られたJITedラストフレームレコードも指
し、ＬＩＦＯ（Last In First Out）のリストを構成す
る（図５）。図５において□はJITedラストフレームレ
コードを表す。黒い□はメソッドＤが非JITedコードを
呼び出す前に作るJITedラストフレームレコードであ
る。JITedラストフレームレコード及びＬＩＦＯリスト
は、各スレッド毎に管理される。
【００１９】JITコードＧＣの手順は以下のとおりであ
る。あるスレッドでＪＩＴコンパイラがメモリ不足にな
ったとき、全スレッドを一時停止させる。次に、各スレ
ッド毎にアクティブなメソッドを発見、すなわちスレッ
ド・スタック中のJITedコードアドレスを発見する。各
スレッドで、現在のスタック・ポインタＳＰ（現在のコ
ンテキストから取得する）から、JITedラストフレーム
レコードのＬＩＦＯリストがない場合はスタックの底ま
で、リストがある場合はリストの最新のJITedラストフ
レームレコードが指すJITedフレームのアドレスまで、
保守的ＧＣ方式を行う。次にJITedラストフレーム方式
を行う。この２方式の実行順序はどちらでもよい。図６
はこれを模式的に表したものである。図６において、JI
TedコードＥのJITedフレームより上のスタック領域（Ｓ
ＰからＥのラベルが付いたフレームまで）は、JITedラ
ストフレームレコードを作らないと決めたポイントから
呼び出された非JITedコードのフレーム、あるいはＣＰ
Ｕ例外にマップされたJava例外を扱う例外ハンドラのフ
レームである。アクティブなメソッドをすべて発見した
後、残りのメソッドについて、実行プロファイル情報を
参考にして、JITedコードを破棄するメソッドを選択す
る。選択方針は例えば、呼び出し回数合計によるヒスト
グラムで、少ない方から選択する。破棄により、ＪＩＴ
コンパイラが現在要求しているメモリ量以上空いたら、
あるいは破棄できるものを全て破棄したら、JITコード
ＧＣを停止する。停止の前に断片化（fragmentation）
した領域をコンパクト化（メモリブロックを移動してで
きるだけ連続になるようにつなげること）してもよい。
る。あるスレッドでＪＩＴコンパイラがメモリ不足にな
ったとき、全スレッドを一時停止させる。次に、各スレ
ッド毎にアクティブなメソッドを発見、すなわちスレッ
ド・スタック中のJITedコードアドレスを発見する。各
スレッドで、現在のスタック・ポインタＳＰ（現在のコ
ンテキストから取得する）から、JITedラストフレーム
レコードのＬＩＦＯリストがない場合はスタックの底ま
で、リストがある場合はリストの最新のJITedラストフ
レームレコードが指すJITedフレームのアドレスまで、
保守的ＧＣ方式を行う。次にJITedラストフレーム方式
を行う。この２方式の実行順序はどちらでもよい。図６
はこれを模式的に表したものである。図６において、JI
TedコードＥのJITedフレームより上のスタック領域（Ｓ
ＰからＥのラベルが付いたフレームまで）は、JITedラ
ストフレームレコードを作らないと決めたポイントから
呼び出された非JITedコードのフレーム、あるいはＣＰ
Ｕ例外にマップされたJava例外を扱う例外ハンドラのフ
レームである。アクティブなメソッドをすべて発見した
後、残りのメソッドについて、実行プロファイル情報を
参考にして、JITedコードを破棄するメソッドを選択す
る。選択方針は例えば、呼び出し回数合計によるヒスト
グラムで、少ない方から選択する。破棄により、ＪＩＴ
コンパイラが現在要求しているメモリ量以上空いたら、
あるいは破棄できるものを全て破棄したら、JITコード
ＧＣを停止する。停止の前に断片化（fragmentation）
した領域をコンパクト化（メモリブロックを移動してで
きるだけ連続になるようにつなげること）してもよい。
【００２０】本発明では、JITedラストフレームレコー
ドを作成しない非JITedコード呼び出しを許し、それに
起因する未発見アクティブメソッドを防ぐために、部分
的に保守的ＧＣ方式を行う。ＪＩＴコンパイラが使用で
きるメモリ量が厳密に限定され、メモリ不足の頻度が高
いシステムでは、JITedラストレコードをできるだけ作
成することによって、JITコードＧＣの効率を高める。
一方、仮想記憶をサポートする、比較的メモリ制限の緩
いシステムでは、JITedラストレコードをあまり作成し
ないことによって、JITedコードの実行性能を重視す
る。このように、本発明は要求されるメモリ・性能トレ
ードオフに応じて、JITedラストレコード作成頻度を加
減することで、保守的ＧＣ一辺倒によるアクティブ・メ
ソッド発見よりも、（偽JITedコードの点で）無駄の少
ない、（スキャン領域を狭い点で）効率の良いシステム
ができる。
ドを作成しない非JITedコード呼び出しを許し、それに
起因する未発見アクティブメソッドを防ぐために、部分
的に保守的ＧＣ方式を行う。ＪＩＴコンパイラが使用で
きるメモリ量が厳密に限定され、メモリ不足の頻度が高
いシステムでは、JITedラストレコードをできるだけ作
成することによって、JITコードＧＣの効率を高める。
一方、仮想記憶をサポートする、比較的メモリ制限の緩
いシステムでは、JITedラストレコードをあまり作成し
ないことによって、JITedコードの実行性能を重視す
る。このように、本発明は要求されるメモリ・性能トレ
ードオフに応じて、JITedラストレコード作成頻度を加
減することで、保守的ＧＣ一辺倒によるアクティブ・メ
ソッド発見よりも、（偽JITedコードの点で）無駄の少
ない、（スキャン領域を狭い点で）効率の良いシステム
ができる。
【００２１】以下に本発明をまとめておく。本発明のＪ
ＩＴコンパイラは、以下の処理を実施する。すなわち、
第１ルーチンが第２ルーチンを呼び出すことを検出した
場合、第２ルーチンが所定の条件を満たしているか判断
するステップと、第２ルーチンが所定の条件を満たして
いる場合には、第１ルーチンのスタック・フレームを指
すレコード（実施例のJITedラストフレームレコード）
を生成するためのコードを第１ルーチンのコード中に生
成するステップとを含む。これにより、所定の条件を満
たすルーチンのスタック・フレームの検出が簡単にな
る。所定の条件は、スタック・フレーム検出の効率化と
レコード作成に関する処理負荷のトレードオフで設定さ
れる場合もある。なお、上記レコードは、当該レコード
の直前に作成されたレコードへのポインタをも含むよう
にすることも考えられる。
ＩＴコンパイラは、以下の処理を実施する。すなわち、
第１ルーチンが第２ルーチンを呼び出すことを検出した
場合、第２ルーチンが所定の条件を満たしているか判断
するステップと、第２ルーチンが所定の条件を満たして
いる場合には、第１ルーチンのスタック・フレームを指
すレコード（実施例のJITedラストフレームレコード）
を生成するためのコードを第１ルーチンのコード中に生
成するステップとを含む。これにより、所定の条件を満
たすルーチンのスタック・フレームの検出が簡単にな
る。所定の条件は、スタック・フレーム検出の効率化と
レコード作成に関する処理負荷のトレードオフで設定さ
れる場合もある。なお、上記レコードは、当該レコード
の直前に作成されたレコードへのポインタをも含むよう
にすることも考えられる。
【００２２】また、所定の条件は、当該コンパイラによ
りコンパイルされていないルーチンとすることもでき
る。さらに、コンパイラによりコンパイルされないルー
チンであり、呼び出される頻度が所定値以下であり、且
つレコードを作成する処理が処理全体の速度を所定基準
以上に低下させないようなルーチンであるか、又はコン
パイラによりコンパイルされないルーチンであり、且つ
当該ルーチンが前記コンパイラでコンパイルされるルー
チンを呼び出す可能性があるという条件、とすることも
できる。前記コンパイラでコンパイルされるルーチンを
呼び出す可能性があるということは、そのコンパイルさ
れるルーチンがさらに上記レコードを作成する可能性が
あるということである。
りコンパイルされていないルーチンとすることもでき
る。さらに、コンパイラによりコンパイルされないルー
チンであり、呼び出される頻度が所定値以下であり、且
つレコードを作成する処理が処理全体の速度を所定基準
以上に低下させないようなルーチンであるか、又はコン
パイラによりコンパイルされないルーチンであり、且つ
当該ルーチンが前記コンパイラでコンパイルされるルー
チンを呼び出す可能性があるという条件、とすることも
できる。前記コンパイラでコンパイルされるルーチンを
呼び出す可能性があるということは、そのコンパイルさ
れるルーチンがさらに上記レコードを作成する可能性が
あるということである。
【００２３】さらに、第２メソッドを呼び出すコードを
第１ルーチンのコード中に生成するステップと、呼び出
すコードの後に、レコードを削除するコードを生成する
ステップとをさらに含むようにすることも考えらる。
第１ルーチンのコード中に生成するステップと、呼び出
すコードの後に、レコードを削除するコードを生成する
ステップとをさらに含むようにすることも考えらる。
【００２４】本発明のガベージ・コレクションは、以下
のような処理を含む。すなわち、スタック内に実行中又
は実行されたルーチンのスタック・フレームを格納する
システムにおいて、所定の条件を満たし且つ所定のコン
パイラ（例えば実施例におけるＪＩＴコンパイラ）によ
りコンパイルされたルーチンに対応するスタック・フレ
ームを指すレコード（例えば実施例におけるJITedラス
トフレームレコード）が格納されている場合であって、
所定のコンパイラによりコンパイルされたルーチンのス
タック・フレームを検出する際には、スタック中の、ス
タック・ポインタからレコードによりポイントされるス
タック・フレーム（実施例では、最新のレコードまで。
但し、これに限定されるものではない。）までの間をス
キャンし、所定のコンパイラによりコンパイルされたル
ーチンのスタック・フレームを検出するステップと、レ
コードによりポイントされるスタック・フレーム及び当
該スタック・フレームから連続してトレースできる、所
定のコンパイラによりコンパイルされたルーチンのスタ
ック・フレームを検出するステップと実行する。これに
より、所定のコンパイラによりコンパイルされたルーチ
ンのスタック・フレームは漏らさず検出できるようにな
る。なお、上記２ステップの順番は入れ替え可能であ
る。
のような処理を含む。すなわち、スタック内に実行中又
は実行されたルーチンのスタック・フレームを格納する
システムにおいて、所定の条件を満たし且つ所定のコン
パイラ（例えば実施例におけるＪＩＴコンパイラ）によ
りコンパイルされたルーチンに対応するスタック・フレ
ームを指すレコード（例えば実施例におけるJITedラス
トフレームレコード）が格納されている場合であって、
所定のコンパイラによりコンパイルされたルーチンのス
タック・フレームを検出する際には、スタック中の、ス
タック・ポインタからレコードによりポイントされるス
タック・フレーム（実施例では、最新のレコードまで。
但し、これに限定されるものではない。）までの間をス
キャンし、所定のコンパイラによりコンパイルされたル
ーチンのスタック・フレームを検出するステップと、レ
コードによりポイントされるスタック・フレーム及び当
該スタック・フレームから連続してトレースできる、所
定のコンパイラによりコンパイルされたルーチンのスタ
ック・フレームを検出するステップと実行する。これに
より、所定のコンパイラによりコンパイルされたルーチ
ンのスタック・フレームは漏らさず検出できるようにな
る。なお、上記２ステップの順番は入れ替え可能であ
る。
【００２５】また、所定の条件は前の段落において述べ
た条件を採用できる。
た条件を採用できる。
【００２６】また、本発明のガベージ・コレクション
は、以下のような処理を実施してもよい。すなわち、ス
タック・ポインタが所定のコンパイラによりコンパイル
されたルーチンのスタック・フレームを指しているか判
断するステップと、スタック・ポインタが所定のコンパ
イラによりコンパイルされたルーチンのスタック・フレ
ームを指している場合には、スタック・ポインタが指し
ているスタック・フレーム及び当該スタック・フレーム
から連続してトレースできる、所定のコンパイラにより
コンパイルされたルーチンのスタック・フレームを検出
するステップと、レコードによりポイントされるスタッ
ク・フレーム及び当該スタック・フレームから連続して
トレースできる、所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
とを実行する。これは、スタック・ポインタが所定のコ
ンパイラによりコンパイルされたルーチンのスタック・
フレームを指している場合には、このスタック・フレー
ムから連続してトレースできる、所定のコンパイラによ
りコンパイルされたルーチンのフレーム・スタックの最
も古いものから、レコードまでの間には、検出すべきス
タック・フレームがない、という性質を利用している。
は、以下のような処理を実施してもよい。すなわち、ス
タック・ポインタが所定のコンパイラによりコンパイル
されたルーチンのスタック・フレームを指しているか判
断するステップと、スタック・ポインタが所定のコンパ
イラによりコンパイルされたルーチンのスタック・フレ
ームを指している場合には、スタック・ポインタが指し
ているスタック・フレーム及び当該スタック・フレーム
から連続してトレースできる、所定のコンパイラにより
コンパイルされたルーチンのスタック・フレームを検出
するステップと、レコードによりポイントされるスタッ
ク・フレーム及び当該スタック・フレームから連続して
トレースできる、所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
とを実行する。これは、スタック・ポインタが所定のコ
ンパイラによりコンパイルされたルーチンのスタック・
フレームを指している場合には、このスタック・フレー
ムから連続してトレースできる、所定のコンパイラによ
りコンパイルされたルーチンのフレーム・スタックの最
も古いものから、レコードまでの間には、検出すべきス
タック・フレームがない、という性質を利用している。
【００２７】また、スタック・ポインタが所定のコンパ
イラによりコンパイルされたルーチンのスタック・フレ
ームを指していない場合には、スタック中の、スタック
・ポインタからレコードによりポイントされるスタック
・フレームまでの間をトレースし、所定のコンパイラに
よりコンパイルされたルーチンのスタック・フレームを
検出するステップを実行するようにもできる。
イラによりコンパイルされたルーチンのスタック・フレ
ームを指していない場合には、スタック中の、スタック
・ポインタからレコードによりポイントされるスタック
・フレームまでの間をトレースし、所定のコンパイラに
よりコンパイルされたルーチンのスタック・フレームを
検出するステップを実行するようにもできる。
【００２８】また、破棄可能なルーチンのコードは、上
述のようにして検出されたスタック・フレームのルーチ
ン以外のルーチンのコードであり、破棄可能である場合
にはそのルーチンのコードを破棄する。なお、所定のコ
ンパイラによるコンパイル中に使用可能なメモリが不足
したことに応答して、所定のコンパイラによりコンパイ
ルされたルーチンのスタック・フレームを検出する処理
を実行する。
述のようにして検出されたスタック・フレームのルーチ
ン以外のルーチンのコードであり、破棄可能である場合
にはそのルーチンのコードを破棄する。なお、所定のコ
ンパイラによるコンパイル中に使用可能なメモリが不足
したことに応答して、所定のコンパイラによりコンパイ
ルされたルーチンのスタック・フレームを検出する処理
を実行する。
【００２９】以上本発明の処理のフローを説明したが、
本発明はこれらの処理を実施する装置や、コンピュータ
にこれらの処理を実施させるプログラムの形態によって
も実施可能である。このプログラムを、フロッピー・デ
ィスクやＣＤ−ＲＯＭ等の記憶媒体又は他の形態の記憶
装置に格納することは、通常当業者が行う事項である。
本発明はこれらの処理を実施する装置や、コンピュータ
にこれらの処理を実施させるプログラムの形態によって
も実施可能である。このプログラムを、フロッピー・デ
ィスクやＣＤ−ＲＯＭ等の記憶媒体又は他の形態の記憶
装置に格納することは、通常当業者が行う事項である。
【００３０】
【発明の実施の形態】本発明の装置構成を図７を用いて
説明する。サーバ・コンピュータ１及びクライアント・
コンピュータ５はネットワーク３を介して接続されてい
る。クライアント・コンピュータ５は、ＪａｖａＶＭ
（Virtual Machine）５２及びＯＳ（Operating Syste
m）５３及びハードウエア（ＣＰＵ及びメモリを含む）
５５を含む。さらに、ＪａｖａＶＭ５２は、Ｊａｖａイ
ンタープリタ５４又はＪａｖａ ＪＩＴコンパイラ５
６、及びガベージ・コレクションを行うガベージ・コレ
クタ６０を含む。インタープリタ５４及びＪＩＴコンパ
イラ５６の両者を有している場合もある。なお、クライ
アント・コンピュータ５は、通常のコンピュータの他、
メモリの大きさが小さかったり、ハードディスク等の補
助記憶装置を含まないような、いわゆるネットワーク・
コンピュータや情報家電の場合もある。
説明する。サーバ・コンピュータ１及びクライアント・
コンピュータ５はネットワーク３を介して接続されてい
る。クライアント・コンピュータ５は、ＪａｖａＶＭ
（Virtual Machine）５２及びＯＳ（Operating Syste
m）５３及びハードウエア（ＣＰＵ及びメモリを含む）
５５を含む。さらに、ＪａｖａＶＭ５２は、Ｊａｖａイ
ンタープリタ５４又はＪａｖａ ＪＩＴコンパイラ５
６、及びガベージ・コレクションを行うガベージ・コレ
クタ６０を含む。インタープリタ５４及びＪＩＴコンパ
イラ５６の両者を有している場合もある。なお、クライ
アント・コンピュータ５は、通常のコンピュータの他、
メモリの大きさが小さかったり、ハードディスク等の補
助記憶装置を含まないような、いわゆるネットワーク・
コンピュータや情報家電の場合もある。
【００３１】サーバ・コンピュータ１では、Ｊａｖａソ
ースコード１０は、Ｊａｖａコンパイラ１２によりコン
パイルされる。このコンパイルの結果が、バイトコード
１４である。このバイトコード１４は、ネットワーク３
を介してクライアント・コンピュータ５に送信される。
バイトコード１４は、クライアント・コンピュータ５内
のＷＷＷブラウザ（World Wide Web Browser）などに設
けられたＪａｖａ仮想マシン（Java VM）５２にとって
ネイティブ・コードであり、実際ハードウエア５５のＣ
ＰＵにて実行する場合には、Ｊａｖａインタープリタ５
４や、ＪａｖａＪＩＴコンパイラ５６を用いる。インタ
ープリタ５４は、実行時にバイトコード１４をデコード
し、命令ごとに用意される処理ルーチンを呼び出して実
行する。一方、ＪＩＴコンパイラ５６は、バイトコード
を事前にあるいは実行する直前にコンパイラを用いてマ
シン・コード５８に変換してそれをＣＰＵで実行する。
ースコード１０は、Ｊａｖａコンパイラ１２によりコン
パイルされる。このコンパイルの結果が、バイトコード
１４である。このバイトコード１４は、ネットワーク３
を介してクライアント・コンピュータ５に送信される。
バイトコード１４は、クライアント・コンピュータ５内
のＷＷＷブラウザ（World Wide Web Browser）などに設
けられたＪａｖａ仮想マシン（Java VM）５２にとって
ネイティブ・コードであり、実際ハードウエア５５のＣ
ＰＵにて実行する場合には、Ｊａｖａインタープリタ５
４や、ＪａｖａＪＩＴコンパイラ５６を用いる。インタ
ープリタ５４は、実行時にバイトコード１４をデコード
し、命令ごとに用意される処理ルーチンを呼び出して実
行する。一方、ＪＩＴコンパイラ５６は、バイトコード
を事前にあるいは実行する直前にコンパイラを用いてマ
シン・コード５８に変換してそれをＣＰＵで実行する。
【００３２】以下、ＪＩＴコンパイラ５６の本発明に関
連する部分及びガベージ・コレクタ６０について説明す
る。
連する部分及びガベージ・コレクタ６０について説明す
る。
【００３３】（１）ＪＩＴコンパイラ５６の本発明に関
連する部分 ＪＩＴコンパイラ５６の本発明に関連する部分の動作を
図８を用いて説明する。JITedコードを生成するとき、
非JITedコードを呼ぶコードを生成する場合がある。Ｊ
ＩＴコンパイラ５６は、非JITedコードの呼び出しを検
出すると（ステップ１００）、決められた規則に基づい
て、それぞれの非JITコード呼び出しを場合分けし、JIT
edラストフレームレコードを生成すべき呼び出しかどう
か判別する（ステップ１１０）。このJITedラストフレ
ームレコードを生成すべきか否かの場合分けは、Javaメ
ソッド（より厳密にはJITedラストフレームレコードを
構成するJITedコード）を直接又は間接的に呼び出す可
能性あるか否かという基準が用いられる。このような場
合にJITedラストフレームレコードを生成しなければ以
下で述べるアクティブ・メソッドの検出処理で漏れが生
じてしまう可能性があるからである。
連する部分 ＪＩＴコンパイラ５６の本発明に関連する部分の動作を
図８を用いて説明する。JITedコードを生成するとき、
非JITedコードを呼ぶコードを生成する場合がある。Ｊ
ＩＴコンパイラ５６は、非JITedコードの呼び出しを検
出すると（ステップ１００）、決められた規則に基づい
て、それぞれの非JITコード呼び出しを場合分けし、JIT
edラストフレームレコードを生成すべき呼び出しかどう
か判別する（ステップ１１０）。このJITedラストフレ
ームレコードを生成すべきか否かの場合分けは、Javaメ
ソッド（より厳密にはJITedラストフレームレコードを
構成するJITedコード）を直接又は間接的に呼び出す可
能性あるか否かという基準が用いられる。このような場
合にJITedラストフレームレコードを生成しなければ以
下で述べるアクティブ・メソッドの検出処理で漏れが生
じてしまう可能性があるからである。
【００３４】では、ある非JITedコードが直接又は間接
的にJavaメソッドを呼び出すことが分かるのかという問
題がある。Ｊａｖａプログラミングの原則は「一度プロ
グラムを書けば、それはどこでも動く」というものであ
る。すなわち、図７のようなシステムにおいては、シス
テム・プログラム以外はＪａｖａでプログラムを書く。
言い換えれば、Ｊａｖａで書かれていないプログラム
は、システム・プログラムであり、その振る舞いはシス
テムにとって既知である。JITedコードが直接呼び出す
非JITedコードには、大きく分けて（１）JavaＶＭ５２
のサービス・ルーチン、（２）ネイティブ・メソッドの
糊付け（glue）コード、（３）ＪＩＴコンパイラがコン
パイルしなかったJavaメソッドの糊付けコード、があ
る。いずれもシステム・プログラムであるから、その振
る舞いはシステムにとって既知でり、それらのコードが
直接又は間接的にJavaメソッドを呼び出すかどうかも分
かる。
的にJavaメソッドを呼び出すことが分かるのかという問
題がある。Ｊａｖａプログラミングの原則は「一度プロ
グラムを書けば、それはどこでも動く」というものであ
る。すなわち、図７のようなシステムにおいては、シス
テム・プログラム以外はＪａｖａでプログラムを書く。
言い換えれば、Ｊａｖａで書かれていないプログラム
は、システム・プログラムであり、その振る舞いはシス
テムにとって既知である。JITedコードが直接呼び出す
非JITedコードには、大きく分けて（１）JavaＶＭ５２
のサービス・ルーチン、（２）ネイティブ・メソッドの
糊付け（glue）コード、（３）ＪＩＴコンパイラがコン
パイルしなかったJavaメソッドの糊付けコード、があ
る。いずれもシステム・プログラムであるから、その振
る舞いはシステムにとって既知でり、それらのコードが
直接又は間接的にJavaメソッドを呼び出すかどうかも分
かる。
【００３５】一般に、非JITedコードがJavaメソッドを
呼び出すということは、ＪａｖａＶＭ５６を新たに起動
することに等しく、その非JITedコード呼び出しのコス
トは高い。従って、そうした非JITedコードの呼び出し
頻度は少ないと予想される。そうした非JITedコード呼
び出しに、JITedラストフレームレコードを構成して
も、実行性能に与える影響は少ない。
呼び出すということは、ＪａｖａＶＭ５６を新たに起動
することに等しく、その非JITedコード呼び出しのコス
トは高い。従って、そうした非JITedコードの呼び出し
頻度は少ないと予想される。そうした非JITedコード呼
び出しに、JITedラストフレームレコードを構成して
も、実行性能に与える影響は少ない。
【００３６】例えば、Javaのシンクロナイズド（synchr
onized）メソッドのコード生成を場合を考える。この場
合には、生成されるJITedコードのプロローグコードに
おけるオブジェクトのロック、エピローグコードのアン
ロックで、サービスルーチンを呼び出す。synchronized
メソッドのロック・アンロックのオーバーヘッドに、さ
らにJITedラストフレームの作成、登録、削除のオーバ
ーヘッドを追加するのは性能上問題がある。そこで、sy
nchronizedメソッドのロック／アンロック・サービスル
ーチン呼び出しならばJITedラストフレームレコードを
構成しない、という規則により、この場合にはJITedラ
ストフレームレコードなしで非JITコードを呼び出し、
実行性能の低下を防ぐ。このsynchronizedメソッドのロ
ック／アンロック・サービスルーチンの場合には、「呼
び出し先の非JITedコードは、呼び出し頻度が少なく、J
ITedラストフレームレコードの作成で重要な性能低下が
生じないような非JITedコードである場合」という規則
をステップ１１０で適用したということも言える。
onized）メソッドのコード生成を場合を考える。この場
合には、生成されるJITedコードのプロローグコードに
おけるオブジェクトのロック、エピローグコードのアン
ロックで、サービスルーチンを呼び出す。synchronized
メソッドのロック・アンロックのオーバーヘッドに、さ
らにJITedラストフレームの作成、登録、削除のオーバ
ーヘッドを追加するのは性能上問題がある。そこで、sy
nchronizedメソッドのロック／アンロック・サービスル
ーチン呼び出しならばJITedラストフレームレコードを
構成しない、という規則により、この場合にはJITedラ
ストフレームレコードなしで非JITコードを呼び出し、
実行性能の低下を防ぐ。このsynchronizedメソッドのロ
ック／アンロック・サービスルーチンの場合には、「呼
び出し先の非JITedコードは、呼び出し頻度が少なく、J
ITedラストフレームレコードの作成で重要な性能低下が
生じないような非JITedコードである場合」という規則
をステップ１１０で適用したということも言える。
【００３７】必要ありとステップ１１０で判断された場
合には、非JITedコード呼び出し前にJITedラストフレー
ムレコードを作成・登録するためのコードを、呼び出し
後にJITedラストフレームレコードを削除するコードを
生成する（ステップ１２０）。作成されるJITedラスト
フレームレコードは、呼び出し側のJITedメソッドのJIT
edフレームを指す。同時に、JITedラストフレームレコ
ードはＬＩＦＯリストを構成する。すなわち、それ以前
のJITedラストフレームレコードへのポインタをも含
む。ＬＩＦＯリストは各スレッドに固有なもので、スレ
ッド管理ブロックで記憶・管理される。記憶するのはメ
イン・メモリ上である。
合には、非JITedコード呼び出し前にJITedラストフレー
ムレコードを作成・登録するためのコードを、呼び出し
後にJITedラストフレームレコードを削除するコードを
生成する（ステップ１２０）。作成されるJITedラスト
フレームレコードは、呼び出し側のJITedメソッドのJIT
edフレームを指す。同時に、JITedラストフレームレコ
ードはＬＩＦＯリストを構成する。すなわち、それ以前
のJITedラストフレームレコードへのポインタをも含
む。ＬＩＦＯリストは各スレッドに固有なもので、スレ
ッド管理ブロックで記憶・管理される。記憶するのはメ
イン・メモリ上である。
【００３８】（２）ガベージ・コレクタ６０の動作 あるスレッドでＪＩＴコンパイラのメモリ要求が満たせ
なくなったとき、そのメソッドは自分以外のスレッドを
全て一時停止し、アクティブ・メソッドを見つける動作
を実施する。各スレッドに対して以下のような動作（図
９）を実行させ、それを全スレッドに対して行う。
なくなったとき、そのメソッドは自分以外のスレッドを
全て一時停止し、アクティブ・メソッドを見つける動作
を実施する。各スレッドに対して以下のような動作（図
９）を実行させ、それを全スレッドに対して行う。
【００３９】まず、現在コード検査のためスレッドのコ
ンテキストを取得する（ステップ１６０）。一時停止し
た時に実行していたコードのプログラム・カウンタ（pr
ogram counter）を得る。それがJITedコードを指してい
れば（ステップ１７０）、対応するメソッドをアクティ
ブ・メソッドとしてマークする（ステップ１８０）。さ
らにこのJITedフレームに連続するJITedフレーム列、別
の言い方をすればこのメソッドを呼んだJITedコードの
フレームからJITedコードアドレスを得て、対応するメ
ソッドをアクティブ・メソッドとしてマークする（ステ
ップ１９０）。マークはメイン・メモリ上に記憶され
る。
ンテキストを取得する（ステップ１６０）。一時停止し
た時に実行していたコードのプログラム・カウンタ（pr
ogram counter）を得る。それがJITedコードを指してい
れば（ステップ１７０）、対応するメソッドをアクティ
ブ・メソッドとしてマークする（ステップ１８０）。さ
らにこのJITedフレームに連続するJITedフレーム列、別
の言い方をすればこのメソッドを呼んだJITedコードの
フレームからJITedコードアドレスを得て、対応するメ
ソッドをアクティブ・メソッドとしてマークする（ステ
ップ１９０）。マークはメイン・メモリ上に記憶され
る。
【００４０】もしステップ１７０で非JITedコードであ
るということが分かれば、コンテキストからスタック・
ポインタＳＰを得る（ステップ２００）。ＳＰの指すア
ドレスから、JITedラストフレームのＬＩＦＯリストの
最新のJITedラストフレームレコードが指すJITedフレー
ムまで、ワード毎にすべての値について、JITedコード
か検査する（ステップ２１０）。すなわち、部分的な保
守的ＧＣ方式を実行するものである。ＬＩＦＯリストが
ない場合、スタック・ポインタＳＰからスタックの底ま
での範囲について、同様に行う。 JITedコードを指して
いれば、対応するメソッドをアクティブ・メソッドとし
てマークする。
るということが分かれば、コンテキストからスタック・
ポインタＳＰを得る（ステップ２００）。ＳＰの指すア
ドレスから、JITedラストフレームのＬＩＦＯリストの
最新のJITedラストフレームレコードが指すJITedフレー
ムまで、ワード毎にすべての値について、JITedコード
か検査する（ステップ２１０）。すなわち、部分的な保
守的ＧＣ方式を実行するものである。ＬＩＦＯリストが
ない場合、スタック・ポインタＳＰからスタックの底ま
での範囲について、同様に行う。 JITedコードを指して
いれば、対応するメソッドをアクティブ・メソッドとし
てマークする。
【００４１】ステップ２１０及びステップ１９０の後
に、JITedラストフレームレコード方式に従って、JITed
ラストフレームレコードのＬＩＦＯリストをたどり、各
JITedラストフレームレコードが指すJITedフレーム列
（直接指示されたJITedフレーム及びそれから連続するJ
ITedフレーム）からJITedコードアドレスを取得する。
それらJITedコードに対応するメソッドをアクティブ・
メソッドとしてマークする（ステップ２２０）。
に、JITedラストフレームレコード方式に従って、JITed
ラストフレームレコードのＬＩＦＯリストをたどり、各
JITedラストフレームレコードが指すJITedフレーム列
（直接指示されたJITedフレーム及びそれから連続するJ
ITedフレーム）からJITedコードアドレスを取得する。
それらJITedコードに対応するメソッドをアクティブ・
メソッドとしてマークする（ステップ２２０）。
【００４２】なお、以下をオプションとして実行するこ
とも可能である。レジスタによるJITedコードの間接呼
び出しがあるシステムの場合、コンテキストから間接呼
び出しで使われる可能性のあるレジスタすべての値を取
得する。その値全てについてJITedコードを指している
かどうか検査し、JITedコードを指していれば、対応す
るメソッドをアクティブ・メソッドとしてマークする。
とも可能である。レジスタによるJITedコードの間接呼
び出しがあるシステムの場合、コンテキストから間接呼
び出しで使われる可能性のあるレジスタすべての値を取
得する。その値全てについてJITedコードを指している
かどうか検査し、JITedコードを指していれば、対応す
るメソッドをアクティブ・メソッドとしてマークする。
【００４３】以上で、あるスレッドのアクティブメソッ
ドがすべてマークできた。なお、マークされたメソッド
以外のメソッドで、メモリ上にあるメソッドのコードを
破棄可能であるとし、全て破棄することも一部破棄する
こともできる（ステップ２３０）。
ドがすべてマークできた。なお、マークされたメソッド
以外のメソッドで、メモリ上にあるメソッドのコードを
破棄可能であるとし、全て破棄することも一部破棄する
こともできる（ステップ２３０）。
【００４４】図１０は、４つのスレッドのスレッド・ス
タックを表している。スレッド・スタックはフレームに
分割されている。アルファベット文字が割り振られたフ
レームは、JITedフレームである。例えばフレームＡ
は、メソッドＡのJITedコードのフレームである。この
例では、スレッド１のＪＩＴコンパイラ動作中にメモリ
不足になったとする。そしてその瞬間にメソッドＡから
メソッドＺまでの２６個のJITedコードが存在するとす
る。また図中、スレッド１の角の取れた□で囲まれたフ
レームは、ＪＩＴコンパイラのフレームである。この例
では、ＪＩＴコンパイラが起動する際には必ずJITedラ
ストフレームが作られる。
タックを表している。スレッド・スタックはフレームに
分割されている。アルファベット文字が割り振られたフ
レームは、JITedフレームである。例えばフレームＡ
は、メソッドＡのJITedコードのフレームである。この
例では、スレッド１のＪＩＴコンパイラ動作中にメモリ
不足になったとする。そしてその瞬間にメソッドＡから
メソッドＺまでの２６個のJITedコードが存在するとす
る。また図中、スレッド１の角の取れた□で囲まれたフ
レームは、ＪＩＴコンパイラのフレームである。この例
では、ＪＩＴコンパイラが起動する際には必ずJITedラ
ストフレームが作られる。
【００４５】本発明を用いたJITコードＧＣは、以下の
ように行われる。まず最初に、スレッド１はスレッド２
乃至４を一時停止させる。スレッド２はJITedラストフ
レームレコードを作らずに非JITedコードを呼びその中
で一時停止している。スレッド３はJITedラストフレー
ムレコードを作って非JITedコードを呼びその中で一時
停止している。スレッド４はJITedコード動作中に一時
停止した。
ように行われる。まず最初に、スレッド１はスレッド２
乃至４を一時停止させる。スレッド２はJITedラストフ
レームレコードを作らずに非JITedコードを呼びその中
で一時停止している。スレッド３はJITedラストフレー
ムレコードを作って非JITedコードを呼びその中で一時
停止している。スレッド４はJITedコード動作中に一時
停止した。
【００４６】次に、スレッド１からスレッド４までそれ
ぞれのスレッドに対して、現在コード検査、部分的保守
的ＧＣ方式、さらにJITedラストフレーム方式でJITedフ
レームを検索する。この例の場合、スレッド１は部分的
保守的ＧＣ方式を省ける。これは、ＪＩＴコンパイラの
フレームより前のフレームにJITedラストフレームレコ
ードが付されているからである。現在コード検査によ
り、スレッド４でメソッドＯとＰのJITedフレームが発
見される。部分的保守的ＧＣ方式により、スレッド２で
メソッドＨのJITedフレームが発見される。またJITedラ
ストフレーム方式でスレッド１でメソッドＡからＤ、ス
レッド２でメソッドＥからＧ、スレッド３でメソッドＩ
からＬのJITedフレームが発見される。結果として、現
在動作中のスレッドのスタックから、１６個のJITedフ
レームが発見され、対応するメソッドＡからＰまでをア
クティブ・メソッドとしてマークする。
ぞれのスレッドに対して、現在コード検査、部分的保守
的ＧＣ方式、さらにJITedラストフレーム方式でJITedフ
レームを検索する。この例の場合、スレッド１は部分的
保守的ＧＣ方式を省ける。これは、ＪＩＴコンパイラの
フレームより前のフレームにJITedラストフレームレコ
ードが付されているからである。現在コード検査によ
り、スレッド４でメソッドＯとＰのJITedフレームが発
見される。部分的保守的ＧＣ方式により、スレッド２で
メソッドＨのJITedフレームが発見される。またJITedラ
ストフレーム方式でスレッド１でメソッドＡからＤ、ス
レッド２でメソッドＥからＧ、スレッド３でメソッドＩ
からＬのJITedフレームが発見される。結果として、現
在動作中のスレッドのスタックから、１６個のJITedフ
レームが発見され、対応するメソッドＡからＰまでをア
クティブ・メソッドとしてマークする。
【００４７】マークされなかったメソッドＱからＺまで
は非アクティブである。したがって、この中の任意のメ
ソッドのJITedコードを破棄してよい。この例では単純
に全部破棄する。JITedコードが選択的に残ったので、
アクティブ・メソッドのJITedコードはメモリ上で断片
化している。コンパクションを行って断片化の割合を減
らし、できるだけ連続した空きメモリをつくる。無条件
に行うコンパクションはJITコードＧＣの時間を引き延
ばすので、この後述べるように再度メモリ不足が起きた
場合に遅らせてもよい。
は非アクティブである。したがって、この中の任意のメ
ソッドのJITedコードを破棄してよい。この例では単純
に全部破棄する。JITedコードが選択的に残ったので、
アクティブ・メソッドのJITedコードはメモリ上で断片
化している。コンパクションを行って断片化の割合を減
らし、できるだけ連続した空きメモリをつくる。無条件
に行うコンパクションはJITコードＧＣの時間を引き延
ばすので、この後述べるように再度メモリ不足が起きた
場合に遅らせてもよい。
【００４８】最後にスレッド１は、一時停止させたスレ
ッド２から４の実行を再開させる。スレッド１は再度メ
モリ割当を要求する。JITコードＧＣで十分な空きメモ
リが確保されていれば、メモリ割当は成功し、引き続き
コンパイルが行われる。
ッド２から４の実行を再開させる。スレッド１は再度メ
モリ割当を要求する。JITコードＧＣで十分な空きメモ
リが確保されていれば、メモリ割当は成功し、引き続き
コンパイルが行われる。
【００４９】他のスレッドで動作するＪＩＴコンパイラ
がメモリを取得した、あるいはJITedコード破棄によっ
てできた空きメモリが不足した等の原因により、再度メ
モリ不足が生じうる場合がある。本例では、一回JITコ
ードＧＣを実行し直す。一般的にはｎ回JITコードＧＣ
を繰り返す。それでもメモリ不足であれば、現在のコン
パイルセッションを中断する。
がメモリを取得した、あるいはJITedコード破棄によっ
てできた空きメモリが不足した等の原因により、再度メ
モリ不足が生じうる場合がある。本例では、一回JITコ
ードＧＣを実行し直す。一般的にはｎ回JITコードＧＣ
を繰り返す。それでもメモリ不足であれば、現在のコン
パイルセッションを中断する。
【００５０】中断した後、ＪＩＴコンパイラが使用する
メモリを減らすために、最適化レベルを１つ下げて、再
びコンパイルする。コンパイルが成功するまでこれを繰
り返す。最も低い最適化レベルでもコンパイルが成功し
なかった場合、このメソッドはコンパイルしない。な
お、再コンパイルが許可されていない場合にもメソッド
のコンパイルを中止する。
メモリを減らすために、最適化レベルを１つ下げて、再
びコンパイルする。コンパイルが成功するまでこれを繰
り返す。最も低い最適化レベルでもコンパイルが成功し
なかった場合、このメソッドはコンパイルしない。な
お、再コンパイルが許可されていない場合にもメソッド
のコンパイルを中止する。
【００５１】
【効果】ＪＩＴコンパイラの使用できるメモリを制限さ
れ、JITedフレームはＣコンパイラの最適化コードのフ
レーム並に最適化され、且つスレッド・スタック上でJI
Tedフレームとその他のフレームが混在する環境におい
て、JITedフレームのみを検出できるようになった。
れ、JITedフレームはＣコンパイラの最適化コードのフ
レーム並に最適化され、且つスレッド・スタック上でJI
Tedフレームとその他のフレームが混在する環境におい
て、JITedフレームのみを検出できるようになった。
【００５２】JITedフレームを検出し、アクティブなメ
ソッドを発見することもできた。
ソッドを発見することもできた。
【００５３】さらに、効率良く且つ高速に、JITedフレ
ームのみを検出できるようにすることもできた。
ームのみを検出できるようにすることもできた。
【００５４】さらに、破棄可能なメソッドのコードを検
出できるようにすることもできた。
出できるようにすることもできた。
【図１】スタック・フレーム例を説明するための図であ
る。
る。
【図２】スタック・フレーム例を説明するための図であ
る。
る。
【図３】保守的ガベージ・コレクション方式の説明のた
めの図である。
めの図である。
【図４】JITedフレームレコードＧＣ方式の説明のため
の図である。
の図である。
【図５】JITedフレームレコードＧＣ方式の説明のため
の図である。
の図である。
【図６】本発明における、JITedコードに対応するフレ
ームの検出を説明するための図である。
ームの検出を説明するための図である。
【図７】本発明における装置構成の一例を示す図であ
る。
る。
【図８】ＪＩＴコンパイラ５６の処理例を示す図であ
る。
る。
【図９】ガベージ・コレクタ６０の処理例を示す図であ
る。
る。
【図１０】本発明の具体例を説明するための図である。
ＳＰ スタック・ポインタ ＳＣＡＮ スキャンすること ＳＴＡＣＫ ＢＵＴＴＯＭ スタックの底 １ サーバ・コンピュータ ３ ネットワーク ５ クライアント・コンピュータ ５２ ＪａｖａＶＭ ５４ Ｊａｖａインタプリタ ５６ Ｊａｖａ ＪＩＴコンパイラ ５８ マシンコード ６０ ガベージ・コレクタ ５３ ＯＳ ５５ ハードウエア（ＣＰＵ及びメモリを含む）
フロントページの続き (56)参考文献 特開 平２−267629（ＪＰ，Ａ) Ｔ．Ｃｒａｍｅｒ他，Ｃｏｍｐｉｌｉ ｎｇ Ｊａｖａ Ｊｕｓｔ ｉｎ Ｔｉ ｍｅ，ＩＥＥＥ ＭＩＣＲＯ，1997，Ｖ ｏｌ．17，Ｎｏ．３，ｐ．36−43 志村浩也他，Ｊａｖａ（ＴＭ）ＪＩＴ コンパイラの試作，情報処理学会研究報 告96−ＡＲＣ−120，Ｖｏｌ．96，Ｎｏ. 106，ｐ．37−42 Ｃ−Ｈ．Ａ．Ｈｓｉｅｂ他，Ｏｐｔｉ ｍｉｚｉｎｇ ＮＥＴ Ｃｏｍｐｉｌｅ ｒｓ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｊａ ｖａ Ｐｅｒｆｏｒｍａｎｃｅ，Ｃｏｍ ｐｕｔｅｒ，1997，Ｖｏｌ．30，Ｎｏ. ６，ｐ．67−75 (58)調査した分野(Int.Cl.7，ＤＢ名) G06F 9/44 G06F 9/45 G06F 12/00 591
Claims (17)
- 【請求項１】プログラムの動作中にコードをコンパイル
できる、所定のコンパイラによるコンパイル方法であっ
て、 第１ルーチンが第２ルーチンを呼び出すことを検出した
場合、第２ルーチンが所定のコンパイラによってコンパ
イルされていないコードであるという条件を満たしてい
るか判断するステップと、 前記第２ルーチンが前記条件を満たしている場合には、
前記第１ルーチンのスタック・フレームを指すレコード
を生成するためのコードを前記第１ルーチンのコード中
に生成するステップと、 を含む、コンパイラによるコンパイル方法。 - 【請求項２】前記レコードは、当該レコードの直前に作
成されたレコードへのポインタをも含む、請求項１記載
のコンパイル方法。 - 【請求項３】前記条件は、 さらに、呼び出される頻度が所定値以下であり、且つ前
記レコードを作成する処理が処理全体の速度を所定基準
以上に低下させないようなルーチンであるという条件を
含む請求項１記載のコンパイル方法。 - 【請求項４】前記条件は、 さらに、当該ルーチンが前記所定のコンパイラでコンパ
イルされるルーチンを呼び出す可能性があるという条件
である請求項１記載のコンパイル方法。 - 【請求項５】前記第２ルーチンを呼び出すコードを前記
第１ルーチンのコード中に生成するステップと、 前記呼び出すコードの後に、前記レコードを削除するコ
ードを生成するステップと、 をさらに含む請求項１記載のコンパイル方法。 - 【請求項６】スタック内に実行中又は実行されたルーチ
ンのスタック・フレームを格納するシステムにおいて、
プログラムの動作中にコードをコンパイルできる所定の
コンパイラによりコンパイルされたルーチンに対応する
スタック・フレームを指すレコードが格納されている場
合に、前記所定のコンパイラによりコンパイルされたル
ーチンのスタック・フレームを検出する方法であって、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
と、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 を含むフレーム検出方法。 - 【請求項７】スタック内に実行中又は実行されたルーチ
ンのスタック・フレームを格納するシステムにおいて、
プログラムの動作中にコードをコンパイルできる所定の
コンパイラによりコンパイルされたルーチンに対応する
スタック・フレームを指すレコードが格納されている場
合に、前記所定のコンパイラによりコンパイルされたル
ーチンのスタック・フレームを検出する方法であって、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
と、 を含むフレーム検出方法。 - 【請求項８】スタック内に実行中又は実行されたルーチ
ンのスタック・フレームを格納するシステムにおいて、
プログラムの動作中にコードをコンパイルできる所定の
コンパイラによりコンパイルされたルーチンに対応する
スタック・フレームを指すレコードが格納されている場
合に、前記所定のコンパイラによりコンパイルされたル
ーチンのスタック・フレームを検出する方法であって、 スタック・ポインタが前記所定のコンパイラによりコン
パイルされたルーチンのスタック・フレームを指してい
るか判断するステップと、 前記スタック・ポインタが前記所定のコンパイラにより
コンパイルされたルーチンのスタック・フレームを指し
ている場合には、前記スタック・ポインタが指している
スタック・フレーム及び当該スタック・フレームから連
続してトレースできる、前記所定のコンパイラによりコ
ンパイルされたルーチンのスタック・フレームを検出す
るステップと、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 を含むフレーム検出方法。 - 【請求項９】スタック・ポインタが前記所定のコンパイ
ラによりコンパイルされたルーチンのスタック・フレー
ムを指していない場合には、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
を含む請求項８記載のフレーム検出方法。 - 【請求項１０】スタック内に実行中又は実行されたルー
チンのスタック・フレームを格納するシステムにおい
て、プログラムの動作中にコードをコンパイルできる所
定のコンパイラによりコンパイルされたルーチンに対応
するスタック・フレームを指すレコードが格納されてい
る場合に、破棄可能なルーチンのコードを破棄する方法
であって、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出する第１検出
ステップと、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出する第２検出ステップ
と、 検出された前記スタック・フレームのルーチン以外のル
ーチンのコードを破棄するステップと、 を含むコード破棄方法。 - 【請求項１１】前記所定のコンパイラによるコンパイル
中に使用可能なメモリが不足したことに応答して、前記
第１検出ステップ以降を実行することを特徴とする請求
項１０記載のコード破棄方法。 - 【請求項１２】プログラムの動作中にコードをコンパイ
ルできる、所定のコンパイラを記憶領域に記憶したコン
ピュータであって、 前記コンパイラは、前記コンピュータの計算処理によ
り、 記憶領域に記憶した第１ルーチンが第２ルーチンを前記
記憶領域から呼び出すことを検出した場合、第２ルーチ
ンが所定のコンパイラによってコンパイルされていない
コードであるという条件を満たしているか判断するステ
ップと、 前記第２ルーチンが前記条件を満たしている場合には、
前記第１ルーチンのスタック・フレームを指すレコード
を記憶領域に生成するためのコードを前記第１ルーチン
のコード中に生成して、記憶領域に記憶するステップ
と、 を実行する、コンピュータ。 - 【請求項１３】スタック内に実行中又は実行されたルー
チンのスタック・フレームが格納され、プログラムの動
作中にコードをコンパイルできる所定のコンパイラによ
りコンパイルされたルーチンに対応するスタック・フレ
ームを指すレコードが格納される場合に、前記所定のコ
ンパイラによりコンパイルされたルーチンのスタック・
フレームを検出するフレーム検出装置であって、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出する手段と、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出する手段と、 を有するフレーム検出装置。 - 【請求項１４】プログラムの動作中にコードをコンパイ
ルできる、コンパイラを格納した記憶媒体であって、 前記コンパイラは、コンピュータに、 第１ルーチンが第２ルーチンを呼び出すことを検出した
場合、第２ルーチンが所定のコンパイラによってコンパ
イルされていないコードであるという条件を満たしてい
るか判断するステップと、 前記第２ルーチンが前記条件を満たしている場合には、
前記第１ルーチンのスタック・フレームを指すレコード
を生成するためのコードを前記第１ルーチンのコード中
に生成するステップと、 を実行させる、記憶媒体。 - 【請求項１５】スタック内に実行中又は実行されたルー
チンのスタック・フレームを格納するシステムにおい
て、プログラムの動作中にコードをコンパイルできる所
定のコンパイラによりコンパイルされたルーチンに対応
するスタック・フレームを指すレコードが格納されてい
る場合に、前記所定のコンパイラによりコンパイルされ
たルーチンのスタック・フレームをコンピュータに検出
させるプログラムを格納した記憶媒体であって、 前記プログラムは、前記コンピュータに、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
と、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 を実行させる、記憶媒体。 - 【請求項１６】スタック内に実行中又は実行されたルー
チンのスタック・フレームを格納するシステムにおい
て、プログラムの動作中にコードをコンパイルできる所
定のコンパイラによりコンパイルされたルーチンに対応
するスタック・フレームを指すレコードが格納されてい
る場合に、前記所定のコンパイラによりコンパイルされ
たルーチンのスタック・フレームをコンピュータに検出
させるプログラムを格納した記憶媒体であって、 前記プログラムは、前記コンピュータに、 スタック・ポインタが前記所定のコンパイラによりコン
パイルされたルーチンのスタック・フレームを指してい
るか判断するステップと、 前記スタック・ポインタが前記所定のコンパイラにより
コンパイルされたルーチンのスタック・フレームを指し
ている場合には、前記スタック・ポインタが指している
スタック・フレーム及び当該スタック・フレームから連
続してトレースできる、前記所定のコンパイラによりコ
ンパイルされたルーチンのスタック・フレームを検出す
るステップと、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 を実行させる、記憶媒体。 - 【請求項１７】スタック内に実行中又は実行されたルー
チンのスタック・フレームを格納するシステムにおい
て、プログラムの動作中にコードをコンパイルできる所
定のコンパイラによりコンパイルされたルーチンに対応
するスタック・フレームを指すレコードが格納されてい
る場合に、破棄可能なルーチンのコードをコンピュータ
に破棄させるプログラムを格納した記憶媒体であって、 前記プログラムは、前記コンピュータに、 前記スタック中の、スタック・ポインタから前記レコー
ドによりポイントされるスタック・フレームまでの間を
スキャンし、前記所定のコンパイラによりコンパイルさ
れたルーチンのスタック・フレームを検出するステップ
と、 前記レコードによりポイントされるスタック・フレーム
及び当該スタック・フレームから連続してトレースでき
る、前記所定のコンパイラによりコンパイルされたルー
チンのスタック・フレームを検出するステップと、 検出された前記スタック・フレームのルーチン以外のル
ーチンのコードを破棄するステップと、 を実行させる、記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26784298A JP3280322B2 (ja) | 1998-05-15 | 1998-09-22 | コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13291898 | 1998-05-15 | ||
| JP10-132918 | 1998-05-15 | ||
| JP26784298A JP3280322B2 (ja) | 1998-05-15 | 1998-09-22 | コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000035890A JP2000035890A (ja) | 2000-02-02 |
| JP3280322B2 true JP3280322B2 (ja) | 2002-05-13 |
Family
ID=26467384
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP26784298A Expired - Fee Related JP3280322B2 (ja) | 1998-05-15 | 1998-09-22 | コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3280322B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8601493B2 (en) | 2005-03-28 | 2013-12-03 | Mitsubishi Electric Corporation | Application controlling apparatus and storage medium which stores software for the apparatus |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3790683B2 (ja) | 2001-07-05 | 2006-06-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピュータ装置、その例外処理プログラム及びコンパイル方法 |
| JP4795138B2 (ja) * | 2006-06-29 | 2011-10-19 | 富士ゼロックス株式会社 | 画像処理装置及びプログラム |
| JP5614348B2 (ja) * | 2011-03-18 | 2014-10-29 | 富士通株式会社 | 命令処理方法、命令処理装置、及び命令処理プログラム |
-
1998
- 1998-09-22 JP JP26784298A patent/JP3280322B2/ja not_active Expired - Fee Related
Non-Patent Citations (3)
| Title |
|---|
| Ｃ−Ｈ．Ａ．Ｈｓｉｅｂ他，Ｏｐｔｉｍｉｚｉｎｇ ＮＥＴ Ｃｏｍｐｉｌｅｒｓ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｊａｖａ Ｐｅｒｆｏｒｍａｎｃｅ，Ｃｏｍｐｕｔｅｒ，１９９７，Ｖｏｌ．３０，Ｎｏ．６，ｐ．６７−７５ |
| Ｔ．Ｃｒａｍｅｒ他，Ｃｏｍｐｉｌｉｎｇ Ｊａｖａ Ｊｕｓｔ ｉｎ Ｔｉｍｅ，ＩＥＥＥ ＭＩＣＲＯ，１９９７，Ｖｏｌ．１７，Ｎｏ．３，ｐ．３６−４３ |
| 志村浩也他，Ｊａｖａ（ＴＭ）ＪＩＴコンパイラの試作，情報処理学会研究報告９６−ＡＲＣ−１２０，Ｖｏｌ．９６，Ｎｏ．１０６，ｐ．３７−４２ |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8601493B2 (en) | 2005-03-28 | 2013-12-03 | Mitsubishi Electric Corporation | Application controlling apparatus and storage medium which stores software for the apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000035890A (ja) | 2000-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6327701B2 (en) | Method and apparatus for finding bugs related to garbage collection in a virtual machine | |
| US6295643B1 (en) | Method and apparatus for improving java virtual machine performance using persistent execution information | |
| US7191441B2 (en) | Method and apparatus for suspending a software virtual machine | |
| Czajkowski | Application isolation in the Java virtual machine | |
| US6317869B1 (en) | Method of run-time tracking of object references in Java programs | |
| US6557168B1 (en) | System and method for minimizing inter-application interference among static synchronized methods | |
| US6757890B1 (en) | Methods and apparatus for enabling local Java object allocation and collection | |
| US6363522B1 (en) | Method and apparatus for handling exceptions as normal control flow | |
| JP2000172512A (ja) | バイトコ―ドを実行するための方法およびデ―タ処理システム | |
| US20040123278A1 (en) | Persistent cache apparatus and methods | |
| US7168071B2 (en) | Method and system of permitting stack allocation to programs having open-world features | |
| US7600223B2 (en) | Abstracted managed code execution | |
| US6735761B1 (en) | Compile method frame detection method and device code discarding method and computer | |
| US6581077B2 (en) | Method and apparatus for storing short-lived objects in a virtual machine | |
| US7743377B2 (en) | Cooperative threading in a managed code execution environment | |
| JP5051961B2 (ja) | モジュール式ガーベッジコレクタを実現するための方法および装置 | |
| US11474832B2 (en) | Intelligently determining a virtual machine configuration during runtime based on garbage collection characteristics | |
| JP3280322B2 (ja) | コンパイル方法、フレーム検出方法及び装置、コード破棄方法、並びにコンピュータ | |
| CN113176926A (zh) | 一种基于虚拟机自省技术的api动态监控方法及系统 | |
| US7549045B2 (en) | Delegate registration in a managed code execution environment | |
| JP4088379B2 (ja) | コンパイル方法及び装置、並びにスタック・トレース方法及び装置 | |
| US20060101439A1 (en) | Memory management in a managed code execution environment | |
| US6978448B1 (en) | Method and apparatus for rewriting bytecodes to minimize runtime checks | |
| JP3807860B2 (ja) | コンパイル方法および装置、並びにメソッド活動度計算方法および装置 | |
| US11789863B2 (en) | On-the-fly remembered set data structure adaptation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080222 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090222 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100222 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110222 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110222 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120222 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120222 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130222 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130222 Year of fee payment: 11 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140222 Year of fee payment: 12 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| LAPS | Cancellation because of no payment of annual fees |