JP2014164379A - 実フットプリント算出方法、該算出方法を用いたインラインするメソッドの決定方法、装置及びプログラム - Google Patents

Abstract

【課題】実フットプリントを算出する技術及び該技術を用いて算出した実フットプリントを用いてインラインするメソッドを決定する技術を提供する。
【解決手段】コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを作成し、HPMを用いて実行された命令をサンプリングし、マップを用いて、サンプリングした命令を該命令が属するメソッドにマップし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として算出し、算出した各メソッドの実フットプリントに基づきインラインするメソッドを決定する。
【選択図】図７

Description

本発明は、オーバーヘッドを抑えつつ実フットプリントを算出する技術に関する。本発明はまた、そのようにして算出する実フットプリントを用いてインラインするメソッドを決定する技術に関する。

インライニングは、メソッドや関数等の定義されたコードを、それを呼び出した箇所に展開して直接埋め込む手法であり、最も効果的なコンパイラ最適化の１つである。インライニングによって、コール／リターンのオーバーヘッドの削減、最適化範囲の拡大、コードの空間的局所性の向上といった効果が得られる。しかし上記のようなメリットがある一方で、過剰にインラインを行うと、キャッシュミスやコンパイル時間の増加といったデメリットも生ずる。そこでインライニングを抑制する仕組みが必要となる。

そのような仕組みの１つとして閾値を用いてインライニングを抑制する技術を開示する従来技術が存在する（例えば、非特許文献１〜５、特許文献１〜２を参照）。この従来技術では、インライニングによる効果とコストとのトレードオフが考慮されて両者のバランスを取るようにインライニングの閾値が決定される。しかしながら、決定された閾値はインライン後の静的フットプリント、即ち、実際には実行されないコードを含むフットプリントに対して適用されるため、実フットプリント、即ち実際に実行されるコードのサイズを効率的に削減できない。例えば、コードの一部のみが実行される静的フットプリントの大きいメソッドがインラインされず、そのメソッドの呼び出しオーバーヘッドのために性能が低下する可能性がある。

また、機械学習により最適なインライニング閾値を算出する技術を開示する従来技術も存在する（非特許文献６を参照）。この技術は、コンパイラ開発者が最適なインライニング閾値を求める際には有益である。しかしながら、機械学習は計算コストが高いため、実行時コンパイラに適用するのは難しい。

更に、インストルメント化されたコードをプログラムに挿入して、呼び出しの順序や呼び出しの頻度についてのプロファイル情報を収集し、収集したプロファイル情報を用いて再コンパイル時に効率的なインライニングを行う技術を開示する従来技術も存在する（例えば、非特許文献７〜９、特許文献２、３を参照）。

更にまた、プログラムの実行トレースに基づきプログラムの共通部分を抽出し、実際に実行される命令の回数に基づいて共通部分を１つにまとめるか否かを決定する技術を開示する従来技術も存在する（特許文献３を参照）。

更にまた、命令の実行頻度を基にしてインライニング後の実フットプリントを見積もる技術を開示する従来技術も存在する（非特許文献１０、１１を参照）。この従来技術では、インストルメント化されたコードをプログラムに挿入してループ内の基本ブロックの１繰り返しごとの平均実行回数が取得される。そして基本ブロック内の命令数とその実行頻度とを用いて、ループの実フットプリントが求められる。

しかしながら、インストルメント化されたコードをプログラムに挿入する手法や、実行トレースを用いる手法は、プロファイルのオーバーヘッドが高く、実行時コンパイラに適用することは難しい。

なお、非特許文献１２は、本発明において利用するハードウェア・パフォーマンス・モニター（Hardware Performance Monitor: HPM）の機能を説明する背景技術として列挙するものである。また、非特許文献１３は、HPMベースのプロファイラの一例を開示する背景技術として列挙するものである。

特開平６−２０２８７５号公報 特開２０１０−１４０３４４号公報 特開２００７−１８２５４号公報

A. Ayers, R. Gottlieb, and R. Schooler, "Aggressive Inlining", Proceedingsof the ACM SIGPLAN Conference on Programming Language Design andImplementation, 1997. M. Arnold, S. Fink, V. Sarkar, and P. Sweeney, "A comparative study ofstatic and dynamic heuristics for inlining", ACM SIGPLAN Workshop on Dynamicand Adaptive Compilation and Optimization, 2000. O. Beohm, D. Citron, G. Harber, M. Klausner, and R. Levin, "AggressiveFunction Inlining with Global Code Reordering", IBM Research Report, H-0247(H0611-009), Nov. 2006. P. P. Chang, S. A. Mahlke, W. Y. Chen, and W. W. Hwu, "Profile-guidedautomatic inline expansion for C programs", Software Practice and Experience22(5), 349-369, May 1992. P. Zhao and J. N. Amaral, "To Inline or Not to Inline ? EnhancedInlining Decision", 16th Workshop on Languages and Compilers for ParallelComputing, 2003. J. Cavazos and M. F. P. O’Boyle, "Automatic Tuning of InliningHeuristics", Proceedings of the 2005 ACM/IEEE SC Conference, 2005. K. Hazelwood and D. Grove, "Adaptive Online Context-Sensitive Inlining",Proceedings of the international symposium on Code generation and optimization:feedbackdirectedandruntime optimization, 2003. M. Arnold,M. Hind, and B. G. Ryder, "Online feedbackdirected optimization of Java.", Proceedingsof the 17th ACM SIGPLAN conference on Object-oriented programming,systems,languages, and applications, 2002. T. Suganuma, T. Yasue, M. Kawahito, H. Komatsu, and T. Nakatani, "Designand Evaluation of Dynamic Optimizations for a Java Just-In-Time Compiler", ACMTransactionsonProgramming Languages and Systems, Vol. 27, No. 4, pages 732 - 785, July 2005. D. R. Chakrabarti and S. Liu, "Inline Analysis: Beyond SelectionHeuristics", Proceedings of the International Symposium on Code Generation andOptimization, 2006. S. McFarling, "Procedure merging with instruction caches", Processdingsof the ACM SIGPLAN Conference on Programming Language Design andImplementation, 1991 H. Inoue and T. Nakatani, "How a Java VM Can Get More from a HardwarePerformance Monitor", Proceedings of the ACM SIGPLAN International Conferenceon Object- Oriented Programming, Systems, Languages, and Applications, 2009. OProfile-A System Profiler for Linux. ［online］、２０１３年８月２８日、［平成２５年２月２１日検索］、インターネット〈URL：http://oprofile.sourceforge.net/about/〉

この発明は、上記の問題点を解決するためになされたものであって、オーバーヘッドを抑えつつ実際に実行されるコードのサイズである実フットプリントを算出する技術、及び算出した実フットプリントに基づきインラインするのに適したメソッドを決定する技術を提供することを目的とする。

上記目的を達成する本発明は、次のような、コンピュータ処理により、メソッドの実フットプリントを算出する方法により実現される。そのような実フットプリント算出方法は、コンピュータが、コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを作成するステップと、前記コンピュータが、ハードウェア・パフォーマンス・カウンタを用いて実行された命令をサンプリングするステップと、前記コンピュータが、前記マップを用いて、サンプリングした命令を該命令が属するメソッドにマップし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として算出するステップとを含む。

上記目的を達成する本発明はまた、次のような、コンピュータ処理により、インラインするメソッドを決定する方法により実現される。そのようなインラインするメソッドの決定方法は、上述した実フットプリント算出方法により、コンピュータが、各メソッドの実フットプリントを算出するステップと、前記コンピュータが、算出した各メソッドの実フットプリントに基づきインラインするメソッドを決定するステップとを含む。

好ましくは、前記マップは、コンパイル済みコードに含まれる各命令と、該命令が属するインラインされたメソッドとの対応関係を示す。そして前記インラインするメソッドを決定するステップは、前記コンピュータが、算出した各メソッドの実フットプリントに基づきインラインされたメソッドの中からインライニングを解除するメソッドを決定するステップを含む。

より好ましくは、前記各メソッドの実フットプリントを算出するステップは、前記コンピュータが、前記メソッドがインラインされて生成された各コンテキストのサイズを、該コンテキストを構成する命令の中で一度でもサンプリングされた命令の総数として算出するステップと、前記コンピュータが、前記メソッドに対応する複数のコンテキストのサイズの合計を前記メソッドの総実フットプリントとして算出するステップとを含む。そして前記インラインするメソッドを決定するステップは、前記コンピュータが、各メソッドの総実フットプリントに基づきインラインされたメソッドの中からインライニングを解除するメソッドを決定するステップを含む。

更に好ましくは、前記インラインするメソッドを決定するステップは、前記コンピュータが、各メソッドについて、該メソッドの総実フットプリントから、前記メソッドに対応する複数のコンテキストのサイズのうち最大のサイズを差し引いた値を削減値として求めるステップと、前記コンピュータが、前記コンパイル済みコードのサイズが目標のコードサイズ以下になるまで、前記各メソッドの削減値をその値の大きい順に前記コンパイル済みコードのサイズから差し引くステップと、前記コンピュータが、前記削減値を差し引かれたメソッドを、インライニングを解除するメソッドとして決定するステップとを含む。

更にまた好ましくは、前記インラインするメソッドを決定するステップは、前記コンピュータが、前記各メソッドの前記削減値を該メソッドに対応する複数のコンテキストのうちサイズが０でないコンテキストの数で割って利益値とするステップを含む。そして前記コンピュータは、前記各メソッドの削減値を前記コンパイル済みコードのサイズから差し引く順番を、前記各メソッドの前記利益値の大きい順とする。

更にまた好ましくは、前記インラインするメソッドを決定するステップは、前記コンピュータが、サイズが０でないコンテキストを複数有さないメソッドを、インライニングを解除するメソッドの対象から除外するステップを含む。これに代えて、或いはこれに加えて、前記インラインするメソッドを決定するステップは、前記コンピュータが、ルートメソッドとしてコンパイルされるメソッドに含まれるメソッドを、インライニングを解除するメソッドの対象から除外するステップを更に含む、請求項６に記載の方法。

また好ましくは、前記インラインするメソッドを決定するステップは、前記コンピュータが、前記目標のコードサイズを、過去に算出された前記各メソッドの総実フットプリントの合計値の中で最大の合計値に所定の削減率を掛けた値として算出するステップを含む。

また好ましくは、前記方法は、前記コンピュータが、前記コンパイル済みコードのサイズが前記目標のコードサイズよりも小さい場合に、インラインするメソッドを決定するための一連のステップの実行を一定期間休止するステップを更に含む。

また好ましくは、前記方法は、前記コンピュータが、前記サンプリングした命令を格納するキャッシュライン数をカウントするステップと、前記キャッシュライン数が所定の閾値より小さいことを条件に、インラインするメソッドを決定するための一連のステップの実行を一定期間休止するステップとを更に含む。

なお、これまでメソッドの実フットプリントを算出する方法、及び、インラインするメソッドを決定する方法として本発明を説明した。しかし本発明は、これら方法をコンピュータに実行させるための実フットプリント算出プログラム、及び、インラインするメソッドを決定するためのインライン対象決定プログラムとして把握することもできる。また本発明は、そのようなプログラムをコンピュータにインストールすることによって実現される実フットプリント算出装置／システム、及び、インラインするメソッドを決定するための装置／システムとして把握することもできる。

本発明は、コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを予め作成しておくことで、ハードウェア・パフォーマンス・カウンタを用いて実行された命令をサンプリングした際に、サンプリングした命令をこれが属するメソッドにマップすることを可能とし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として算出する。結果、本発明によれば、HPMベースのプロファイリングを利用して、オーバーヘッドを抑えつつ実フットプリントを見積もることができる。また本発明は、該算出方法により求めた実フットプリントに基づきインラインするメソッドを決定するので、実際に実行されるコードのサイズを効率的に削減できる。本願発明のその他の効果については、各実施の形態の記載から理解される。

本発明の実施形態に係るコンピュータ・システム１００のハードウェア構成の一例を示す。 図２（ａ）は、本発明の実施形態に係るインライン対象決定のメカニズムの概要を示す図である。図２（ｂ）は、本発明の実施形態に係るインライン対象決定プログラムのソフトウェア構成を説明する図である。 図３（ａ）は、マップを構成する４種のデータ構造間の関係を説明する図である。図３（ｂ）は、インラインされたメソッド間の階層関係の一例を示す図である。 図４（ａ）は、インライニング・コンテキスト３３０と、メソッドサイズ・デスクリプタ３４０のデータ構造を示す図である。図４（ｂ）は、実フットプリントを算出する関数countSizeの擬似コードの一例を示す図である。 図５（ａ）は、インラインしない利益を算出する関数computeBenefitの擬似コードの一例を示す図である。図５（ｂ）は、インラインしないメソッドを選択する関数selectUninliningTargetの擬似コードの一例を示す図である。 動的コンパイラ２２８による処理のフローチャートの一例を示す図である。 プロファイラ２２０による処理全体のフローチャートの一例を示す図である。 図８（ａ）は、実フットプリント算出処理全体のフローチャートの一例を示す図である。図８（ｂ）は、関数countSizeの処理のフローチャートの一例を示す図である。 関数selectUninliningTargetsの処理のフローチャートの一例を示す図である。 図１０（ａ）は、従来技術と本発明とで相対的なスループットを比較した実験結果を示す図である。図１０（ｂ）は、従来技術と本発明とで相対的な命令キャッシュミスを比較した実験結果を示す図である。 図１１（ａ）は、従来技術と本発明とで相対的なコンパイル時間を比較した実験結果を示す図である。図１１（ｂ）は、本発明のオーバーヘッドを測定した実験結果を示す図である。

以下、本発明の実施形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。

図１は、本発明を実施するのに好適なコンピュータ・システム１００のハードウェア構成の一例を示す。コンピュータ・システム１００は、バス１０６に接続されたメインCPU（中央処理装置）１０２とメイン・メモリ１０４を含んでいる。CPU１０２は好ましくは、32ビット又は64ビットのアーキテクチャに基づくものであり、例えば、インテル社のCore i（商標）シリーズ、Core 2（商標）シリーズ、Atom（商標）シリーズ、Xeon（商標）シリーズ、Pentium（登録商標）シリーズ、Celeron（登録商標）シリーズ、AMD社のPhenom（商標）シリーズ、Athlon（商標）シリーズ、Turion（商標）シリーズ又はSempron（商標）が使用されうる。メイン・メモリ１０４は好ましくは、1GB以上の容量、より好ましくは、2GB以上の容量をもつものであってよい。

バス１０６には、ディスプレイ・コントローラ１０８を介して、ディスプレイ１１０、例えば液晶ディスプレイ（ＬＣＤ）が接続されうる。ディスプレイ１１０は、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インタフェースで表示するために使用される。

バス１０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ１１２を介して、ディスク１１４、例えばシリコン・ディスク又はハードディスクが接続されうる。バス１０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ１１２を介して、任意的に、ドライブ１１６、例えばＣＤ、ＤＶＤまたはＢＤドライブが接続されうる。バス１０６にはさらに、任意的に、キーボード・マウスコントローラ１１８又はＵＳＢバス（図示せず）を介して、キーボード１２０及びマウス１２２が接続されうるが、本発明を実施する上では必要ない。

ディスク１１４には、オペレーティング・システム、J2EEなどのJava（登録商標）処理環境、Java（登録商標）アプリケーション、Java（登録商標）仮想マシン（VM）を提供するプログラム、その他のプログラム及びデータが、メイン・メモリ１０４にロード可能なように記憶されている。

オペレーティング・システムは、例えば、LINUX（登録商標）、マイクロソフト・コーポレーションが提供するWindows（登録商標）オペレーティング・システム、アップル・コンピュータ・インコーポレイテッドが提供するMacOS（登録商標）若しくはiOS（登録商標）、XWindow Systemが備えるUNIX（登録商標）系システム（たとえば、インターナショナル・ビジネス・マシーンズ・コーポレーション（登録商標）が提供するAIX（登録商標））でありうる。

上記ディスク１１４には更に、オペレーティング・システムと協働してCPU１０２に命令を与え、本発明を実施するためのコンピュータ・プログラムを記録することができる。即ち、上記ディスク１１４には、コンピュータ・システム１００にインストールされ、コンピュータ・システム１００を本発明の実施形態による実フットプリント算出装置／システムとして機能させる実フットプリント算出プログラム、コンピュータ・システム１００を本発明の実施形態によるインライン対象決定装置／システムとして機能させるインライン対象決定プログラム、及びそれら関連データを記録することができる。

上記実フットプリント算出プログラムは、マップ作成モジュールと、割り込みハンドラと、見積りモジュールとを含む。これらプログラム及びモジュールは、CPU１０２に働きかけて、コンピュータ・システム１００を、各々後述するマップ作成部２３４と、割り込みハンドラ２０６と、見積り部２２４としてそれぞれ機能させる。また、上記インライン対象決定プログラムは、実フットプリント算出プログラムの上記構成要素に加えて、選択モジュールを含む。これらプログラム及びモジュールは、CPU１０２に働きかけて、コンピュータ・システム１００を、各々後述するマップ作成部２３４と、割り込みハンドラ２０６と、見積り部２２４と、選択部２２６としてそれぞれ機能させる。

上記コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。ドライブ１１６は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭまたはＢＤからプログラムをディスク１１４にインストールするために使用されうる。

通信インタフェース１２６は、例えばイーサネット（登録商標）・プロトコルに従う。通信インタフェース１２６は、通信コントローラ１２４を介してバス１０６に接続され、コンピュータ・システム１００を通信回線１２８に物理的に接続する役割を担い、コンピュータ・システム１００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境に基づくもの、又は、無線ＬＡＮ環境、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどのＷｉ−Ｆｉ規格に基づくものであってもよい。

以上から、本発明の実施態様において使用されるコンピュータ・システム１００は、通常のパーソナルコンピュータ、ワークステーション、メインフレームなどの情報処理装置、又は、これらの組み合わせによって実現されることが容易に理解されるであろう。なお、上記説明した構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。

図２（ａ）は、本発明のインライン対象決定メカニズムの概要を示す図である。コンパイラは、インライニングを含む様々な最適化を行ってコードを生成し（１）、コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを作成する（２）。続いてアプリケーションによりコンパイル済みのコードが実行され（３）、その間プロファイラは、ハードウェア・パフォーマンス・カウンタを用いて実行されている命令をサンプリングする。そしてプロファイラは、作成されたマップを参照して、サンプリングした命令を該命令が属するメソッドにマップし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として見積もる（４）。プロファイラは、見積もった実フットプリントに基づきインライニングを解除すべきメソッドを決定することでインラインすべきメソッドを決定し、コンパイラにインライニング解除のための再コンパイルを指示する（５）。以下、図２（ｂ）を参照して各構成要素を詳細に説明する。

図２（ｂ）は、図１に示すコンピュータ・システム１００のソフトウェアの構成の一例を示す図である。CPU１０２は、ディスク１１４からJava（登録商標）仮想マシン（VM）と、本発明の実施形態に係る実フットプリント算出プログラムをその一部とするインライン対象決定プログラムを含むプログラムとをメイン・メモリ１０４に読み出し実行することにより、オペレーティング・システム２０４、仮想マシン２１０、プロファイラ２２０、及び動的コンパイラ２２８をメイン・メモリ１０４に展開する。CPU１０２はまたパフォーマンス監視部（performance monitoring unit: PMU）２０２を有する。

PMU２０２は、CPU１０２内部の挙動について指定されたイベントの発生を監視し、内部カウンタによりイベントの発生をカウントしたり、カウント値が閾値に達したときに指定された処理を行ったりする、最近のプロセッサが一般的に備えている機能である。監視対象の代表的なものとしては、ＣＰＵ１０２の実行サイクル数、実行命令数、分岐予測ミス数、データキャッシュミス数などがある。本発明においては実行された命令をサンプリングするために、後述するプロファイラ２２０によりPMU２０２の機能が利用される。

オペレーティング・システム２０４は、CPU１０２やメモリの管理など、コンピュータ・システム１００が有する基本的な機能を提供するソフトウェアである。オペレーティング・システム２０４はまた、実行された命令をサンプリングするために後述するプロファイラ２２０により用いられる割り込みハンドラ２０６を有する。割り込みハンドラによる処理の詳細は、プロファイラ２２０に関連して後述する。

仮想マシン２１０は、バイトコードの低速実行（ｉｎｔｅｒｐｒｅｔ）、およびコンパイル済みコードの実行を行うエミュレータである。仮想マシン２０６は、実行部２１２とディスパッチャ２１８とを含み、実行部２１２は、インタープリタ２１４と、コンパイル済みコード実行部２１６とを含んで構成される。

ディスパッチャ２１８は、後述する動的コンパイラ２２８が生成したコンパイル済みコードを保存するメモリ領域であるコード・キャッシュ２３６を参照して次に実行するバイトコードアドレスから始まるコンパイル済みコードがコード・キャッシュ２３６に保存されている否かを判定する。インタープリタ２１４は、コンパイル済みコードが存在しない場合に、処理対象のバイトコードを低速に実行する。コンパイル済みコード実行部２１６は、コンパイル済みコードが存在する場合、コード・キャッシュ２３６からコンパイル済みコードを取得して実行する。

プロファイラ２２０は、２種類のプロファイリングを行うプロファイラであり、それぞれのプロファイリングの結果に基づきインラインすべきメソッドを選択し、選択したメソッド情報を次にコンパイル対象とすべきプログラム領域の情報と共に後述する動的コンパイラ２２８に対し出力する。そのようなプロファイラ２２０は、検出部２２２と、見積り部２２４と、選択部２２６とを含んで構成される。

検出部２２２は、実行プログラムの起動直後の一定期間、実行部２１２により頻繁に実行されるプログラム領域を検出する第１のプロファイリングを行い、第１のプロファイリングの結果を選択部２２６に対して出力する。選択部２２６は、頻繁に実行されるプログラム領域からそこに含まれるメソッドを探索し、その静的フットプリントと許容される単一メソッドのコードサイズとを比較して、インライン対象とするメソッドを選択する。選択部２２６によりインライン対象として選択されたメソッドと頻繁に実行されるプログラム領域についての情報は、後述する動的コンパイラ２２８に対して出力される。なお、許容される単一メソッドのコードサイズは、インライニングによるメリットとデメリットとのバランスを考慮して予め設定されるコードサイズである。なお、静的フットプリントに基づくインラインするメソッドの選択は、上記方法に限定されず、他の方法によってもよい。但し、第１のプロファイリングの結果に基づくインライニングでは、より積極的にインライニングを行うことが好ましい。

見積り部２２４は、ハードウェア・パフォーマンス・カウンタを用いて実行された命令をサンプリングし、サンプリングした命令を該命令が属するメソッドにマップし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として算出する、第２のプロファイリングを行う。ここで上記マッピングは、コンパイル済みコードに含まれる各命令がどのインラインされたメソッドに属するかを示すマップを参照して行われ、該マップは、後述する動的コンパイラ２２８によって作成される。マッピングの詳細は、図４（ａ）、（ｂ）、及び、図８（ａ）、（ｂ）を参照して後述する。また、第２のプロファイリングの結果は選択部２２６に対して出力され、選択部２２６は、算出された各メソッドの実フットプリントに基づきインラインするメソッドを選択する。

実行された命令のサンプリングは具体的には次のようにして行う。即ち、見積り部２２４は、PMU２０２に対し監視したいハードウェア・イベントとして実行命令数が所定の閾値を超えるイベントを指定する。見積り部２２４はまた、PMU２０２に対し実行命令数が指定した所定の閾値に達したときに、割り込みハンドラ２０６を起動するように指定する。これにより、PMU２０２は、実行命令数をカウントするカウンタが所定の閾値を超えると割り込みを生成し、生成された割り込みにより起動された割り込みハンドラ２０６は、PMU２０２から報告を受けた割り込みを起こした命令のアドレスをバッファ２０８に格納する。見積り部２２４は、システムコールによりサンプリングを開始し、その後バッファ２０８が割り込みを起こした命令のアドレスで一杯になるまでブロックされる。ブロックが解除されると見積り部２２４は、サンプリング結果をバッファ２０８から取得する。

また実フットプリントの見積りはより具体的には次のようにして行われる。即ち、見積り部２２４は、メソッドがインラインされて生成された各コンテキストのサイズを、該コンテキストを構成する命令の中で一度でもサンプリングされた命令の総数として算出する。また見積り部２２４は、上記メソッドに対応する複数のコンテキストのサイズの合計を上記メソッドの総実フットプリントとして算出する。見積り部２２４はこのメソッドの総実フットプリントを、メソッドの実フットプリントとして扱う。そして選択部２２６は、各メソッドの総実フットプリントに基づきインラインされたメソッドの中からインライニングを解除するメソッドを決定することにより、インラインするメソッドを選択する。

各メソッドの総実フットプリントに基づきインライニングを解除するメソッドの選択は具体的には次のようにして行う。まず選択部２２６は、各メソッドについて、該メソッドの総実フットプリントから、該メソッドに対応する複数のコンテキストの各サイズのうち最大のサイズを差し引き、この値を、該メソッドをインライニングの対象から除外した場合に全体のコードサイズから削減される削減値として求める。ここで、総実フットプリントから最大のコンテキストのサイズを差し引くのは、インライニングされているメソッドは、該メソッドがコンパイルされた際に生成されるコンテキストを含むからである。即ち、あるメソッドをインライニングの対象から除外したとしても、そのルートメソッドについてのコードサイズは残るためである。

次に選択部２２６は、各メソッドの削減値を該メソッドに対応する複数のコンテキストのうちサイズが０でないコンテキストの数、即ちアクティブなコンテキストの数で割り、この値を、該メソッドをインライニングの対象から除外することにより得られる利益の大きさを示す利益値とする。ここで、各メソッドの削減値を対応するアクティブなコンテキストの数で割るのは、該メソッドをインライニングの対象から除外するために再コンパイルするそのコストを考慮に入れるためである。これはまた、コール／リターンのオーバーヘッドによるデメリットがコードサイズの削減によるメリットよりも相対的に大きくなる小さなサイズのメソッドをアンインライニング対象から除外することにも繋がる。

そして選択部２２６は、コンパイル済みコードのサイズが目標のコードサイズ以下になるまで、コンパイル済みコードのサイズから各メソッドの削減値をその利益値の大きい順に差し引き、最終的に残ったメソッドをインラインするメソッドとして選択する。言い換えると、選択部２２６は、その削減値をコンパイル済みコードのサイズから差し引いたメソッドを、インライニングを解除するメソッドとして決定する。なお、選択部２２６は、アクティブなコンテキストを複数有さないメソッドを、インライニングを解除するメソッドの対象から除外する。これは、アクティブなコンテキストをたった１つしか有さないメソッドは重複したコードを持たないことを意味するためである。また選択部２２６は、ルートメソッドとしてコンパイルされるメソッドに含まれるメソッドを、インライニングを解除するメソッドの対象から除外する。これは、過剰なインライニングの解除により、コードの呼び出し回数が増加しパス長が長くなることを防ぐためである。なお、目標のコードサイズは、過去に算出された各メソッドの総実フットプリントの合計値の中で最大の合計値に所定の削減率（一例として０．９）を掛けた値として算出してよい。

上記見積り部２２４による第２のプロファイリング及び第２プロファイリングの結果に基づく選択部２２６によるアンインライニング対象の選択は、動的コンパイラ２２８による最初のコンパイル後所定の間隔で定期的に行う。但し、コンパイル済みコードのサイズが目標のコードサイズよりも小さい場合は、上記見積り部２２４及び選択部２２６による一連の処理の実行を一定期間休止してよい。これに代えて又はこれに加えて、見積り部２２４は、サンプリングした命令を格納するキャッシュライン数をカウントし、キャッシュライン数が所定の閾値より小さいことを条件に、上記見積り部２２４及び選択部２２６による一連の処理の実行を一定期間休止してよい。

動的コンパイラ２２８は、プロファイラ２２０により出力される２種類のプロファイリング結果それぞれに基づき、次にコンパイル対象とすべきプログラム領域に対してインライニングを含む最適化処理を施して実行時コンパイルを行うコンパイラである。動的コンパイラ２２６は、最適化部２２８と、コード生成部２３０と、マップ作成部２３２とを含んで構成される。

最適化部２２８は、最初のコンパイル時においては、第１のプロファイリング結果に基づき実行頻度の高いプログラム領域に対してインライニングを含む最適化処理を行う。最適化部２２８はまた、最初のコンパイル後においては、第２のプロファイリング結果に基づきインラインされたメソッドをアンインライニングする処理を行う。コード生成部２３２は、最適化部２３０により出力された最適化済みのコードをネイティブコードに変換し、コード・キャッシュ２３６に格納する。

マップ作成部２３４は、コンパイル時において、コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを作成する。上述したように、マップ作成部２３４により作成されたマップは、サンプリングした命令を該命令が属するメソッドにマップするマッピングのために、ランタイム時に見積り部２２４により使用される。ここで、図３（ａ）、（ｂ）を参照して、マップ作成部２３４により作成されるマップの一例を説明する。

図３（ａ）に示すように、マップ作成部２３４は、キャッシュライン・アレイ（cache line array）３１０、コード・アレイ(codearray)３２０、インライニング・コンテキスト(inlining contex) ３３０、メソッドサイズ・デスクリプタ(method-size descriptor)３４０の４種類のデータ構造によってマップを構成し、それぞれのインスタンスをコンパイル時に生成する。キャッシュライン・アレイ３１０とコード・アレイ３２０のペアは、単一のコンパイル済みメソッドに該メソッドのアドレス・レンジを介してリンクされる。このためある命令がサンプリングされた場合、対応するアレイのペアの各エントリの識別は、その命令のアドレスが、それらアレイのペアにリンクされるメソッドのアドレス・レンジ内に存在するか否かを判定することにより行う。以下図３（ａ）を参照して個々のデータ構造について説明するが、具体例として図中記載するMethod A, B,Cそれぞれの間には、図３（ｂ）に示す階層関係が成り立っているものとする。即ち、Method A内でMethodBが１回呼び出され、MethodB内でMethodCが２回呼び出されているものとする。

キャッシュライン・アレイ３１０は、アクセスされたキャッシュライン数の合計をカウントするために使用するものである。各エントリは、１ビットフィールド３０２を有し、以下の式（１）、（２）によって計算されるキャッシュラインのオフセット（Cache line offset）により索引付けされる。サンプリングされた命令に対応するエントリの１ビットフィールドの値が０の場合、アクセスされたキャッシュラインの合計数が１増加され、かつ、同一命令についての重複したカウントを避けるためにそのフィールドは値１に設定される。
Cache line offset = Code offset>> log₂(Size of a cache line) - (1)
Code offset = instruction address - Code start address - (2)

コード・アレイ３２０は、メソッドごとの実行された命令数の合計をカウントするために使用するものである。各エントリは、コンパイル済みメソッドに含まれる１命令に対応し、上記式（２）によって計算されるコード・オフセット（Code offset）により索引付けされる。各エントリは、インラインされているコンテキストを指すポインタを格納するフィールド３０４と、対応する命令が実行されたか否かを示すアクセス・ビット・フィールド３０６とを有する。アクセス・ビット・フィールド３０６は、同一命令についての重複したカウントを避けながら少なくとも一回実行された命令の合計数をカウントするために、該エントリへの最初のアクセス時に設定される。

インライニング・コンテキスト３３０は、インラインしているコンテキストを表し、図４（ａ）に示すデータ構造４０２を有する。データ構造４０２の詳細については後述する。インライニング・コンテキスト３３０の各インスタンスは、メソッドがインラインされるとき、又はコンパイルされるときに生成され、対応するメソッドサイズ・デスクリプタ３４０のインスタンスに関連付けられる。インライニング・コンテキスト３３０の各インスタンスを指すポインタは、そのインラインされたメソッド内の命令に対応するコード・アレイ３２０のエントリ内に格納される。メソッドが複数のコールサイトでインラインされる場合、１のメソッドに対し複数のインライニング・コンテキストのインスタンスが生成されることに留意されたい。

メソッドサイズ・デスクリプタ３４０は、インラインされたメソッドのサイズを算出するために使用するものであり、図４（ａ）に示すデータ構造４０４を有する。メソッドサイズ・デスクリプタ３４０の各インスタンスは、メソッドに１対１に対応してメソッドごとユニークである。

ここで図４（ａ）を参照して、インライニング・コンテキスト３３０のデータ構造４０２と、メソッドサイズ・デスクリプタ３４０のデータ構造４０４とを説明する。図４（ａ）に示すデータ構造４０２は、int型のsizeと、データ構造Contextの参照型のparentと、データ構造MethodSizeの参照型のmtdとから構成される。インライニング・コンテキスト３３０のインスタンスが生成されると、size は値0で初期化され、図４（ｂ）を参照して後述するように、最終的にコンテキストのサイズがそのコンテキストを構成する命令の中で一度でもサンプリングされた命令の総数として設定される。一方、parentには、親の関係にあるインライニング・コンテキスト３３０のインスタンスへのポインタが格納され、また、mtdにはメソッドサイズ・デスクリプタ３４０の対応するインスタンスへのポインタが格納される。

なお、インライニング・コンテキスト３３０のsizeに関して、コンテキストを構成する命令は、対応するインラインされたメソッドに属する命令と、該メソッドにインラインされた他のメソッドに属する命令の両方を含むことに留意されたい。例えば、図３（ａ）及び（ｂ）に示す例を用いて説明すると、メソッドＣはメソッドＢにインラインされていることから、コンテキスト２のサイズは、コンテキスト３及び４に含まれる実行された命令の数を含む。以下では、インライニング・コンテキスト３３０の任意のエントリのsizeやparentを、該エントリが表すコンテキストのsizeやparentと記載することもあることに留意されたい。

図４（ａ）に示すデータ構造４０４は、int型のsize、maxSize、numActve、及びnumContextsと、データ構造Contextの配列型のcontextsとから構成される。メソッドサイズ・デスクリプタ３４０のインスタンスが生成されると、size、maxSize、numActve、及びnumContextsはそれぞれ値0で初期化される。そして、図４（ｂ）を参照して後述するように、sizeには最終的にそのメソッドに対応する複数のコンテキストのサイズの合計として算出される総実フットプリントが設定される。またmaxSizeには、最終的にメソッドに対応する複数のコンテキストのサイズのうち最大のサイズが設定される。またnumActiveには、最終的にメソッドに対応する複数のコンテキストのうち、サイズが０でないコンテキスト、即ちアクティブなコンテキストの数が設定される。またnumContextsには、最終的にメソッドに対応するコンテキストの数、即ち該メソッドを呼び出すコールサイトのうち、メソッドがインラインされたコールサイトの数が設定される。またcontextsには、そのメソッドに対応する全てのコンテキストが設定される。以下では、メソッドサイズ・デスクリプタ３４０の任意のエントリのsizeやmaxSizeやnumActveを、該エントリが表すメソッドのsizeやmaxSizeやnumActveと記載することもあることに留意されたい。

次に図４（ｂ）を参照して、上記説明した４種類のデータ構造により構成されるマップを用いた実フットプリントの算出方法を説明する。図４（ｂ）は、実フットプリントを算出する関数countSizeの擬似コードの一例を示す図である。関数countSizeは、ランタイム時に見積り部２２４によってサンプリングされた命令を該命令が属するメソッドにマップする際に呼び出される。即ち見積り部２２４は、サンプリングされた命令を取得すると、上述した式（２）を用いてその命令のアドレスから対応するコード・アレイ３２０のエントリを識別する。そして、見積り部２２４は、識別したコード・アレイ３２０のエントリのアクセス・ビットが設定されていないことを条件に、そのコード・アレイ３２０のエントリのポインタから辿られるインライニング・コンテキスト３３０のインスタンスに対して関数countSizeを呼び出して実フットプリントをカウントする。

関数countSizeが呼び出されると、まず、引数として渡されたポインタが指すインライニング・コンテキスト３３０のエントリ（以下、単に「現在のコンテキスト」という）のsizeが０であるか否かが確認され、０である場合に、対応するメソッドサイズ・デスクリプタ３４０のエントリ（以下、単に「対応するメソッド」という）のnumActiveの値が１増加される。また、現在のコンテキストのsizeと対応するメソッドのsizeをそれぞれ１増加される。続いて、現在のコンテキストのsizeが、対応するメソッドのmaxSizeと比較して大きい場合に、そのmaxSizeの値が現在のコンテキストのsizeで更新される。最後に、現在のコンテキストのsizeを、その親であるコンテキストのsizeに加算するために、親のインライニング・コンテキスト３３０のエントリのポインタを引数として再帰的に関数countSizeが呼び出される。

次に図５（ａ）、（ｂ）を参照して、メソッドサイズ・デスクリプタ３４０を用いてアンインラインすべき対象メソッドを選択する方法を説明する。図５（ａ）は、インラインしない利益を算出する関数computeBenefitの擬似コードの一例を示す。また、図５（ｂ）は、インラインしないメソッドを選択する関数selectUninliningTargetの擬似コードの一例を示す図である。関数computeBenefit及び関数selectUninliningTargetは、実行された命令がサンプリングされている間、選択部２２６により所定の間隔で定期的に呼び出される。関数computeBenefitは呼び出されると、引数として渡されたポインタが指すメソッドサイズ・デスクリプタ３４０のエントリが表すメソッドの利益値を返す。このメソッドの利益値は、メソッドのsizeからメソッドのmaxsizeを差し引き、これをメソッドのnumActiveで割ることにより算出される。

関数selectUninliningTargetは呼び出されると、まず、過去に算出された各メソッドの総実フットプリントの合計値の中で最大の合計値(maxSize)に所定の削減率(targetReductionRatio)を掛けることでターゲットとすべき目標サイズ（targetSize）を算出する。また、現在のコードサイズから目標サイズ（targetSize）を差し引いて目標削減量（reducedTarget）を求め、これが０以下であれば処理を終了し、０以下でなければインラインされたメソッドを、関数computeBenefitにより求めた利益値の大きい順に並べ替える。また削減サイズ（reducedSize）を０で初期化する。そして、並べ替えたインラインされたメソッドから順に１のメソッドを取り出し、取り出した現在のメソッドのアクティブなコンテキスト数（numActive）が１より大きいことを条件に、現在のメソッドをインラインしないメソッドに登録し、かつ、削減サイズ（reducedSize）に現在のメソッドの削減値を加算する。かかる処理を、削減サイズ（reducedSize）が目標削減量（reducedTarget）より大きくなるまで、又は次のインラインされたメソッドがなくなるまで繰り返す。

次に図６〜図９を参照して、動的コンパイラ２２８及びプロファイラ２２０の動作を説明する。図６は、動的コンパイラ２２８による処理のフローチャートの一例を示す図である。図７は、プロファイラ２２０による処理全体のフローチャートの一例を示す図である。図８（ａ）は、プロファイラ２２０による実フットプリント算出処理全体のフローチャートの一例を示す図である。図８（ｂ）は、関数countSizeの処理のフローチャートの一例を示す図である。図９は、関数selectUninliningTargetsの処理のフローチャートの一例を示す図である。

図６に示すフローチャートは、プロファイラ２２０によって第１のプロファイリングが終了し、動的コンパイラ２２８が第１のプロファイリングの結果としてインライン対象のメソッドと頻繁に実行されるプログラム領域についての情報を取得することにより開始される。ステップ５００において、動的コンパイラ２２８は、頻繁に実行されるプログラム領域に対し、インライニングを含む最適化処理を行う。続いて、動的コンパイラ２２８は、最適化処理済みのコードをコンパイルし、ネイティブコードを生成する（ステップ６０２）。

続いて動的コンパイラ２２８は、生成したコードに含まれる各命令と、インラインされたメソッドとの対応を示すマップを作成する（ステップ６０４）。続いて動的コンパイラ２２８は、再コンパイルのリクエストがあったか否かを判定する（ステップ６０６）。該判定は、再コンパイルのリクエストを受けるまで繰り返される（ステップ６０６：ＮＯ）。一方、再コンパイルのリクエストがあった場合（ステップ６０６：ＹＥＳ）、動的コンパイラ２２８は、プロファイラ２２０から第２のプロファイリングの結果として、アンインライン対象のメソッドについての情報を取得し、アンインライン対象のメソッドについてインライニングを解除する処理を行う（ステップ６０８）。その後動的コンパイラ２２８は、インライニング解除の最適化処理済みのコードに対し再コンパイルを行い、ネイティブコードを生成する（ステップ６１０）。その後プロファイラはステップ６０６へ戻って一連の処理を繰り返す。

図７に示すフローチャートは、第１のプロファイリング結果に基づきコンパイルされたコードの実行中及び第２のプロファイル結果に基づき再コンパイルされたコードの実行中に所定の間隔で定期的に開始される。ステップ７００において、プロファイラ２２０は全てのカウンタを初期化する。続いてプロファイラ２２０は、ハードウェア・パフォーマンス・カウンタを用いて実行された命令をサンプリングする（ステップ７０２）。続いてプロファイラ２２０は、動的コンパイラ２２８によって作成されたマップを用いて、サンプリングされた命令をインラインされたメソッド及びキャッシュラインにそれぞれマッピングし、インラインされたメソッドの実フットプリントとアクセスされたキャッシュライン数を算出する（ステップ７０４）。算出処理の詳細は図８（ａ）及び（ｂ）を参照して後述する。続いてプロファイラ２２０は、命令が十分にサンプリングされたか否かを判定する（ステップ７０６）。命令が十分にサンプリングされていないと判定した場合（ステップ７０６：ＮＯ）、プロファイラ２２０は、ステップ７０２の処理へ戻る。

一方、命令が十分にサンプリングされたと判定した場合（ステップ７０６：ＹＥＳ）、プロファイラ２２０はネイティブコードの目標とすべき目標サイズ（targetSize）を算出する（ステップ７０８）。上述したように、目標サイズは、過去に算出した各メソッドの総実フットプリントの合計値の最大値に所定の削減率を掛けることによって求めることができる。但し、最初のサンプリングにおいては、目標サイズは、現在のネイティブコードのサイズに所定の削減率を掛けた値とする。続いてプロファイラ２２０は、現在のネイティブコードのサイズから目標サイズを引くことにより、目標削減量（reducedTarget）を算出する（ステップ７１０）。

続いてプロファイラ２２０は、目標削減量（reducedTarget）の値が０以下であるか否かを判定する（ステップ７１２）。目標削減量（reducedTarget）の値が０以下である場合（ステップ７１２：ＹＥＳ）、続いてプロファイラ２２０は、アクセスされたキャッシュライン数が所定の閾値以下であるか否かを判定する（ステップ７１４）。アクセスされたキャッシュライン数が所定の閾値以下である場合（ステップ７１４：ＹＥＳ）、プロファイラ２２０は処理を終了する。一方、目標削減量（reducedTarget）の値が０より大きい場合（ステップ７１２：ＮＯ）、又はアクセスされたキャッシュライン数が所定の閾値より大きい場合（ステップ７１４：ＮＯ）、プロファイラ２２０はステップ７１６の処理へ進み、インラインされているメソッドの実フットプリントに基づいてインライニングを解除すべきメソッドを選択し、その後処理を終了する。

図８（ａ）に示すフローチャートは、図７に示すフローチャートのステップ７０４の処理の詳細を示す。処理はステップ８００で開始し、プロファイラ２２０は、サンプリングされた次の命令があるか否かを判定する。サンプリングされた次の命令が存在しない場合（ステップ８００：ＮＯ）、プロファイラ２２０は処理を終了する。一方、サンプリングされた次の命令がある場合（ステップ８００：ＹＥＳ）、続いてプロファイラ２２０は、上述した式（１）及び（２）を用いてサンプリングされた命令のアドレスからキャッシュライン・オフセットを算出し、対応するキャッシュライン・アレイのエントリを識別する（ステップ８０２）。

続いてプロファイラ２２０は、識別したエントリの１ビットフィールドの値が０であるか否かを判定する（ステップ８０４）。識別したエントリの１ビットフィールドの値が０である場合（ステップ８０４：ＹＥＳ）、続いてプロファイラ２２０は、アクセスされたキャッシュラインの合計値を１増加し、その後識別したエントリの１ビットフィールドの値を１に設定する（ステップ８０６）。一方識別したエントリの１ビットフィールドの値が０でない場合（ステップ８０４：ＮＯ）、またはステップ８０６から、プロファイラ２２０はステップ８０８の処理へ進み、上述した式（２）を用いてサンプリングされた命令のアドレスからコード・オフセットを算出し、これを用いて対応するコード・アレイのエントリを識別し、サンプリングされた命令に対応するインラインしているコンテキストへのポインタを取得する。続いてプロファイラ２２０は、ステップ８０８で取得したポインタを引数として、関数countSizeを呼び出し（ステップ８１０）、その後ステップ８００の処理に戻る。関数countSizeの処理の詳細は図８（ｂ）を参照して後述する。

図８（ｂ）に示すフローチャートは、図８（ａ）に示すフローチャートのステップ８１０の処理の詳細を示す。処理はステップ８２０で開始し、プロファイラ２２０は、引数として渡されたポインタが指すインライニング・コンテキスト３３０のエントリが表すコンテキストを現在のコンテキストとし、現在のコンテキストのsizeが０であるか否かを判定する。続いてプロファイラ２２０は、現在のコンテキストに対応するインラインされたメソッドのnumActiveを１増加する（ステップ８２２）。

続いてプロファイラ２２０は、現在のコンテキストのsize及び対応するインラインされたメソッドの現在のsizeをそれぞれ１増加する（ステップ８２４）。続いてプロファイラ２２０は、現在のコンテキストのsizeが対応するインラインされたメソッドのmaxSizeより大きいか否かを判定し（ステップ８２６）、現在のコンテキストのsizeが対応するインラインされたメソッドのmaxSizeよりも大きい場合（ステップ８２６：ＹＥＳ）、対応するインラインされたメソッドのmaxSizeを現在のコンテキストのsizeで更新する（ステップ８２８）。

現在のコンテキストのsizeが対応するインラインされたメソッドのmaxSize以下の場合（ステップ８２６：ＮＯ）、又はステップ８２８から、プロファイラ２２０はステップ８３０へ処理を進め、現在のコンテキストに親の関係にあるコンテキストが存在するか否かを判定する。親の関係にあるコンテキストが存在する場合（ステップ８３０：ＹＥＳ）、プロファイラ２２０は、親のコンテキストを指すポインタを引数として関数countSizeを再帰的に呼び出す（ステップ８３２）。親の関係にあるコンテキストが存在しない場合（ステップ８３０：ＮＯ）、又はステップ８３２の後プロファイラ２２０は処理を終了する。

図９に示すフローチャートは、図７に示すフローチャートのステップ７１６の処理の詳細を示す。処理はステップ９００で開始し、プロファイラ２２０は、インラインされている各メソッドについて、該メソッドをインライニングの対象から除外することにより得られる利益の大きさを示す利益値を上述した方法により算出する。続いてプロファイラ２２０は、算出した利益値の大きい順にインラインされているメソッドを並べ替える（ステップ９０２）。続いてプロファイラ２２０は、削減サイズ（reduceSize）を０で初期化する。

続いてプロファイラ２２０は、利益値の大きい順に並べ替えられたインラインされているメソッドの中に処理すべき次のメソッドＭがあるか否かを判定する（ステップ９０６）。処理すべき次のメソッドＭがある場合（ステップ９０６：ＹＥＳ）、プロファイラ２２０はこれを現在のメソッドＭとして、現在のメソッドＭのnumActiveが１よりも大きいか否かを判定する（ステップ９０８）。現在のメソッドＭのnumActiveが１以下の場合（ステップ９０８：ＮＯ）、プロファイラ２２０はステップ９０６へ戻って一連の処理を繰り返す。一方、現在のメソッドＭのnumActiveが１よりも大きい場合（ステップ９０８：ＹＥＳ）、続いてプロファイラ２２０は、現在のメソッドＭをインラインしないメソッドとして登録する（ステップ９１０）。

続いてプロファイラ２２０は、現在のメソッドＭのsize（総実フットプリント）から、現在のメソッドＭに対応するコンテキストのsizeの中で最大のsizeを引いた値を、削減サイズ（reduceSize）に加算する（ステップ９１２）。続いてプロファイラ２２０は、削減サイズ（reduceSize）が、図７のステップ７１０で求めた目標削減量(reducedTarget)以上であるか否かを判定する（ステップ９１４）。削減サイズ（reduceSize）が目標削減量(reducedTarget)より小さい場合（ステップ９１４：ＮＯ）、プロファイラ２２０はステップ９０６へ戻って一連の処理を繰り返す。一方、削減サイズ（reduceSize）が目標削減量(reducedTarget)以上である場合（ステップ９１４：ＹＥＳ）、又は、ステップ９０６において処理すべき次のメソッドＭがない場合（ステップ９０６：ＮＯ）、プロファイラ２２０は処理を終了する。

次に図１０及び図１１を参照して本発明の実験結果について説明する。実験の条件は以下の通りである。
・実装対象
IBM （商標）Java（商標）Just-in-Time(JIT) コンパイラ 64ビット
・プラットフォーム
2コア、3.84GHzのPower7（商標）プロセッサ、AIX（商標）6.1オペレーティング・システム
・使用したベンチマーク
SPECjvm2008に含まれる実フットプリントの大きいCC(compiler.compiler)、CS(compiler.sunflow)、XML(xml.transform)と、DT(DayTrader/WebSphere 8.5)
・本発明を適用するプロファイラの動作
Java（商標）仮想マシンの起動から３６０秒、通常のコンパイルがある程度終了するのを待つ
６０秒間命令をサンプリングした後、各メソッドの実フットプリントを算出する
総実フットプリントの１０％の削減を目標とする
・比較対象
AggInl：サーバのように長時間実行されるアプリケーション用の積極的なインライニング閾値を使用
NoInl：インライニングを行わない
Normlnl：クライアントアプリケーション向けの標準的なインライニング閾値を使用
AggInl + UnInl：本発明
AggInl + Prof：本発明のプロファイラのみを稼動（オーバーヘッド測定用）
AggInl + HPM：本発明のHPMのカウンタのみを稼動（オーバーヘッド測定用）

図１０（ａ）は、従来技術と本発明とで相対的なスループットを比較した実験結果を示す。なお、以下に説明する４つのグラフはいずれもAggInlの値をベースとしており、図１０（ａ）のグラフは、コンパイル終了後のピーク性能を比較している。図１０（ａ）のグラフが示すように、本発明の手法を適用した場合は、平均で２％、最大２．７％（DT）の性能向上がみられる。ウェブアプリケーション上で動作するDTにおいて最大の性能向上が見られたことから、本発明の手法は長時間実行されるアプリケーションに適しているといえる。また、標準的なインライニング閾値を使用するNormlnlでは、CSを除き性能の改善が見られない。このことから、サイズの大きなアプリケーションではインライニング閾値を下げることで性能を改善するのは難しいといえる。

図１０（ｂ）は、従来技術と本発明とで相対的な命令キャッシュミスを比較した実験結果を示す。本発明の手法では、積極的なインライニング閾値を使ってインライニングを行った後、インライニングを解除して総実フットプリントを１０％の削減しているため、平均で１０％、最大で１６％（XML）L２命令キャッシュミスが減少している。なお、インライニングを行わないNoInlや、標準的なインライニング閾値を使用するNormlnlは、本発明の手法よりも低いキャッシュミスを示している。しかし、図１０（ａ）に関して説明したように、Normlnlでは、CSを除き性能の改善が見られない。これはキャッシュミスが低くても、標準的なインライニング閾値を使用することからパス長が増加し、その結果性能が低下したためと考えられる。

図１１（ａ）は、従来技術と本発明とで相対的なコンパイル時間を比較した実験結果を示す。また、図１１（ｂ）は、本発明のオーバーヘッドを測定した実験結果を示す。本発明の手法では、積極的なインライニング閾値を使ってインライニングを行った後、インライニングを解除するためのプロファイリングや再コンパイルを行うため、平均で３０％のコンパイル時間の増加と、平均で１１％のプロファイリングオーバーヘッドが見られる。しかしながら上述したように、本発明の手法は長時間実行されるアプリケーションに適しており、このようなアプリケーションを対象とすれば、コンパイル時間の増加は大きな問題とならない。例えば負荷の低いときにコンパイルを行うことができる。また、プロファイラのオーバーヘッドは、命令のサンプリング頻度を減少させる（即ち、サンプリング時間を増加させる）ことにより、実フットプリント測定の精度を落とすことなく、削減することが可能である。なお、実験では、実施時間短縮のためにHPMによる命令のサンプリング頻度を最大にしており、そのためオーバーヘッドが大きくなっている。なお、最適化終了後においてはプロファイラは活動しないため、オーバーヘッドはなくなる。

以上、実施形態を用いて本願発明の説明をしたが、本願発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更又は改良を加えることが可能であることが当業者に明らかである。以上のように、上記の実施形態に変更又は改良を加えた形態も当然に本発明の技術的範囲に含まれる。

なお、特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り任意の順序で実現しうることに留意すべきである。また、前の処理の出力を後の処理で用いる場合でも、前の処理と後の処理の間に他の処理が入ることは可能である場合があること、又は間に他の処理が入るように記載されていても前の処理を後の処理の直前に行うよう変更することも可能である場合があることも留意されたい。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」、「続いて、」等を用いて説明したとしても、この順で実施することが必須であることを必ずしも意味するとは限らない。

Claims (15)

1. コンピュータ処理により、メソッドの実フットプリントを算出する方法であって、
   コンピュータが、コンパイル済みコードに含まれる各命令がどのメソッドに属するかを示すマップを作成するステップと、
   前記コンピュータが、ハードウェア・パフォーマンス・カウンタを用いて実行された命令をサンプリングするステップと、
   前記コンピュータが、前記マップを用いて、サンプリングした命令を該命令が属するメソッドにマップし、各メソッドの実フットプリントを、該メソッドに属する命令の中で一度でもサンプリングされた命令の総数として算出するステップと、
   を含む方法。
2. コンピュータ処理により、インラインするメソッドを決定する方法であって、
   前記コンピュータが、請求項１に記載の方法により各メソッドの実フットプリントを算出するステップと、
   前記コンピュータが、算出した各メソッドの実フットプリントに基づきインラインするメソッドを決定するステップと、を含む方法。
3. 前記マップは、コンパイル済みコードに含まれる各命令と、該命令が属するインラインされたメソッドとの対応関係を示し、前記インラインするメソッドを決定するステップは、前記コンピュータが、算出した各メソッドの実フットプリントに基づきインラインされたメソッドの中からインライニングを解除するメソッドを決定するステップを含む、請求項２に記載の方法。
4. 前記各メソッドの実フットプリントを算出するステップは、前記コンピュータが、前記メソッドがインラインされて生成された各コンテキストのサイズを、該コンテキストを構成する命令の中で一度でもサンプリングされた命令の総数として算出するステップと、前記コンピュータが、前記メソッドに対応する複数のコンテキストのサイズの合計を前記メソッドの総実フットプリントとして算出するステップとを含み、前記インラインするメソッドを決定するステップは、前記コンピュータが、各メソッドの総実フットプリントに基づきインラインされたメソッドの中からインライニングを解除するメソッドを決定するステップを含む、請求項３に記載の方法。
5. 前記インラインするメソッドを決定するステップは、前記コンピュータが、各メソッドについて、該メソッドの総実フットプリントから、前記メソッドに対応する複数のコンテキストのサイズのうち最大のサイズを差し引いた値を削減値として求めるステップと、前記コンピュータが、前記コンパイル済みコードのサイズが目標のコードサイズ以下になるまで、前記各メソッドの削減値をその値の大きい順に前記コンパイル済みコードのサイズから差し引くステップと、前記コンピュータが、前記削減値を差し引かれたメソッドを、インライニングを解除するメソッドとして決定するステップとを含む、請求項４に記載の方法。
6. 前記インラインするメソッドを決定するステップは、前記コンピュータが、前記各メソッドの前記削減値を該メソッドに対応する複数のコンテキストのうちサイズが０でないコンテキストの数で割って利益値とするステップを更に含み、前記各メソッドの削減値を前記コンパイル済みコードのサイズから差し引く順番を、前記各メソッドの前記利益値の大きい順とする、請求項５に記載の方法。
7. 前記インラインするメソッドを決定するステップは、前記コンピュータが、サイズが０でないコンテキストを複数有さないメソッドを、インライニングを解除するメソッドの対象から除外するステップを更に含む、請求項６に記載の方法。
8. 前記インラインするメソッドを決定するステップは、前記コンピュータが、ルートメソッドとしてコンパイルされるメソッドに含まれるメソッドを、インライニングを解除するメソッドの対象から除外するステップを更に含む、請求項６に記載の方法。
9. 前記インラインするメソッドを決定するステップは、前記コンピュータが、前記目標のコードサイズを、過去に算出された前記各メソッドの総実フットプリントの合計値の中で最大の合計値に所定の削減率を掛けた値として算出するステップを更に含む、請求項５に記載の方法。
10. 前記コンピュータが、前記コンパイル済みコードのサイズが前記目標のコードサイズよりも小さい場合に、インラインするメソッドを決定するための一連のステップの実行を一定期間休止するステップを更に含む、請求項５に記載の方法。
11. 前記コンピュータが、前記サンプリングした命令を格納するキャッシュライン数をカウントするステップと、前記キャッシュライン数が所定の閾値より小さいことを条件に、インラインするメソッドを決定するための一連のステップの実行を一定期間休止するステップとを更に含む、請求項４に記載の方法。
12. 請求項２乃至１１のいずれかに一項に記載の方法の各ステップを前記コンピュータに実行させる、インラインするメソッドを決定するためのプログラム。
13. 請求項２乃至１１のいずれかに一項に記載の方法の各ステップを実行するように適合された手段を備える、インライニング対象決定装置。
14. 請求項１に記載の方法の各ステップを前記コンピュータに実行させる、実フットプリント算出プログラム。
15. 請求項１に記載の方法の各ステップを実行するように適合された手段を備える、実フットプリント算出装置。

Images