(57)【要約】      （修正有）【課題】ダイナミックに適用可能なフィードバックまたは持続的に格納されるプロファイルデータを提供する。【解決手段】プロセスクローニングアプリケーション環境においてインクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングするシステムであって、実行しているマスタランタイムシステムプロセス３３のメモリ空間を、プロセスリクエストに応答する、子ランタイムシステムプロセス３４として、クローニングし、該子ランタイムシステムプロセスを実行する、ランタイム環境３１と、プロファイリングデータ４９を付加的に収集することによって、該子ランタイムシステムプロセスの実行をプロファイリングする、コレクタ３９とを備える、システム。【選択図】図２
2005216288.tif 000002
【特許請求の範囲】
【請求項１】
プロセスクローニングアプリケーション環境においてインクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングするシステムであって、
実行しているマスタランタイムシステムプロセスのメモリ空間を、プロセスリクエストに応答する、子ランタイムシステムプロセスとして、クローニングし、該子ランタイムシステムプロセスを実行する、ランタイム環境と、
プロファイリングデータを付加的に収集することによって、該子ランタイムシステムプロセスの実行をプロファイリングする、コレクタと
を備える、システム。
【請求項２】
前記子ランタイムシステムプロセスのメモリ空間に、前記プロファイリングデータを一時的に格納するように、規定される、メモリバッファをさらに備える、請求項１に記載のシステム。
【請求項３】
前記ランタイム環境は、前記メモリバッファから、実行しているアプリケーションマネージャプロセスへと、前記プロファイリングデータを周期的に通信する、請求項２に記載のシステム。
【請求項４】
前記子ランタイムシステムプロセスにおいて前記アプリケーションマネージャプロセスとともに保持されるプロファイリング実行スレッドと、
該アプリケーションマネージャプロセスからのデータリクエストに応答する、該プロファイリング実行スレッドを介して前記プロファイリングデータを提供する応答と、
をさらに備える、請求項３に記載のシステム。
【請求項５】
前記プロファイリング実行スレッドは、プロセス間通信メカニズムを含む、請求項４に記載のシステム。
【請求項６】
前記プロファイリングデータは、前記アプリケーションマネージャプロセスへの通信が完了するときにリセットされる、請求項３に記載のシステム。
【請求項７】
デバイスのシャットダウンにおいて、または、周期的に、前記プロファイリングデータを持続的に格納するファイルをさらに備える、請求項１に記載のシステム。
【請求項８】
前記ランタイム環境は、前記ファイルから、実行しているアプリケーションマネージャプロセスへと、前記プロファイリングデータを通信する、請求項７に記載のシステム。
【請求項９】
オブジェクト指向プログラムコードとして提供され、アプリケーションモデルと関連付けられている、ソース定義からの少なくとも１つのクラスの表現を含むアプリケーションモデルをさらに備えるシステムであって、前記子ランタイムプロセスは、１つのこのようなアプリケーションモデル特有のクラスローダインスタンスを選択し、前記ランタイム環境は、該子ランタイムシステムプロセスによって選択された該アプリケーションモデルを、実行しているアプリケーションマネージャプロセスに通信する、請求項１に記載のシステム。
【請求項１０】
前記プロファイリングデータを統合するように、前記プロファイリングデータをオブジェクト指向プログラムコードとして提供されたソース定義として定義されるマスタウォームアッププログラムをさらに備える、請求項１に記載のシステム。
【請求項１１】
実行しているアプリケーションマネージャプロセスの実行が終了するときに、前記マスタウォームアッププログラムをファイルに持続的に格納するファイルマネージャをさらに備えるシステムであって、前記ランタイム環境は、前記マスタウォームアッププログラムを該ファイルから取り出し、該マスタウォームアッププログラムを、実行しているさらなるマスタランタイムシステムプロセスのメモリ空間に、解釈し、インスタンス化し、ウォームアップする、請求項１０に記載のシステム。
【請求項１２】
前記ランタイム環境は、前記さらなるマスタランタイムシステムプロセスのメモリ空間を、プロセスリクエストに応答する、さらなる子ランタイムシステムプロセスとしてクローニングし、該さらなる子ランタイムシステムプロセスを実行する、請求項１１に記載のシステム。
【請求項１３】
前記マスタランタイムシステムプロセスの実行の間、前記マスタウォームアッププログラムをダイナミックに更新するアプリケーションマネージャプログラムをさらに備えるシステムであって、前記ランタイム環境は、該マスタウォームアッププログラムを、該マスタランタイムシステムプロセスのメモリ空間に、解釈し、インスタンス化し、ウォームアップする、請求項１０に記載のシステム。
【請求項１４】
前記プロファイリングデータは、クラス初期化、およびダイナミックコンパイルについて選択された方法を含む群から選択されるデータを含む、請求項１に記載のシステム。
【請求項１５】
前記マスタランタイムシステムプロセスのメモリ空間を前記子ランタイムシステムプロセス用の別のメモリ空間にコピーすることによって、該子ランタイムシステムプロセスをインスタンス化するプロセスクローニングメカニズムをさらに備える、請求項１に記載のシステム。
【請求項１６】
前記マスタランタイムシステムプロセスのメモリ空間への参照を前記子ランタイムシステムプロセス用の別のメモリ空間にコピーすることによって、該子ランタイムシステムプロセスをインスタンス化し、該マスタランタイムシステムプロセスのメモリ空間のコピーを、該子ランタイムシステムプロセスが、該参照されたマスタランタイムシステムプロセスのメモリ空間を変更することを必要とするまで遅らせる、書き込み時コピープロセスクローニングメカニズムをさらに備える、請求項１に記載のシステム。
【請求項１７】
前記マスタランタイムシステムプロセスは、前記プロセスリクエストを受け取ることに関連して、スリープ状態にされる、請求項１に記載のシステム。
【請求項１８】
前記子ランタイムシステムプロセス上のオペレーティングシステムレベルリソース管理パラメータを設定するリソースコントローラをさらに備える、請求項１に記載のシステム。
【請求項１９】
前記オブジェクト指向プログラムコードは、Ｊａｖａ（登録商標）プログラミング言語で書かれている、請求項１に記載のシステム。
【請求項２０】
前記マスタランタイムシステムプロセスおよび前記子ランタイムシステムプロセスは、Ｊａｖａ（登録商標）バーチャルマシンである、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、プロファイリングデータのトラッキングに関し、具体的には、アプリケーション環境をクローニングするプロセスにおけるインクリメンタルプロファイリングデータを、ダイナミックかつ持続的にトラッキングするシステムおよび方法に関する。
【背景技術】
【０００２】
マイクロプロセッサ設計およびコンポーネント統合における最近の進歩は、より幅広い範囲のデバイスが、複雑さを増す機能性および「ソフト」機能を提供することを可能にしている。ソフト機能は、デバイスの動作を向上させ、カスタム化するソフトウェアアプリケーションを含む。これらのデバイスには、デスクトップコンピュータおよびラップトップコンピュータなどの標準的なコンピュータデバイス、携帯情報端末などの携帯用コンピュータデバイス、ならびに、携帯電話、メッセージ機能付きポケベル、ゲーム機、およびセットトップボックスなどの民生用デバイスが含まれる。殆どのデバイスが、現在では、ソフト機能および他の拡張機能をサポートするオペレーティングシステムを含む。
【０００３】
このようなソフトウェアのアップグレートが可能なデバイスによって提供される、強化された能力はまた、ある特定のユーザの期待を生み出す。ユーザは、技術に精通していないことが多く、アーキテクチャにおける挑戦が原因で性能が損なわれること、例えば、遅いか、またはむらがあるアプリケーション性能に我慢ができないことが多い。同様に、ユーザは、概して、マルチタスキングを通じてシステムレベルで実行される、多くの別個のアプリケーションにアクセスできることを期待する。ユーザにとって、広く利用可能なソフトウェアアプリケーションは、複数のプラットフォームにわたって、一貫性および強化されたエクスポージャを介する、プラスの経験を保証するものである。しかし、ソフトウェア開発者にとっては、異なるコンピュータプラットフォームに対してソフトウェアアプリケーションを設計することには、開発費の増大と、サポートされたアーキテクチャのそれぞれに対する継続的なサポートおよびアップグレードの責任とが伴う。
【０００４】
マネージドコードプラットフォームは、マシンに依存しない、アーキテクチャ中立型の動作環境を提示することによって、複数のプラットフォームをサポートしようとしているソフトウェア開発者に１つの解決策を提供する。マネージドコードプラットフォームは、ユーザアプリケーションとしてオペレーティングシステムによって実行されるが、互換性があるアプリケーションが動作できるバーチャルランタイム環境を提供する、プログラミング言語コンパイラおよびインタープリタを含む。例えば、Ｊａｖａ（登録商標）プログラミング言語で書かれたアプリケーションは、Ｊａｖａ（登録商標）バーチャルマシン（ＪＶＭ）ランタイム環境と組み合わされる場合、マシン特有の環境および設定状況に依存しない異機種コンピュータシステム上で動作し得る。Ｊａｖａ（登録商標）プログラミング言語の概要は、Ｐ．ｖａｎ  ｄｅｒ  Ｌｉｎｄｅｎによる「Ｊｕｓｔ  Ｊａｖａ（登録商標）」（Ｃｈ．１、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．、２ｄ  ｅｄ．  １９９７）に記載されている。この文献の開示内容は、本明細書中、参考のため援用される。ＪＶＭは、メモリが制約された民生用デバイスを含む、あらゆるコンピュータデバイスにポートされ得る、Ｊａｖａ（登録商標）動作環境全体にとって重要なコンポーネントである。
【０００５】
マネージドコードプラットフォームは、概して、単一のアプリケーションインスタンスの単調な実行向けに設計される。マネージドコードプラットフォームの複数のインスタンスは、マルチタスキング動作をシミュレートするように実行される。しかし、このように同時性を強制することによって、いくつかの性能の問題点が発生する。第１に、それぞれのインスタンスは、起動遷移を招く。実行可能な起動時のデータは、遅い持続性格納装置から読み出される必要があり、遅い初期アプリケーション性能につながる。同様に、メモリは、インスタンス間で共有されず、追加されるインスタンスが、それぞれ、クラスを別々にローディングし、インスタンス作成することによって、プラットフォームのメモリフットプリント全体を増大させる。さらに、データ依存性および遅れたシステム状態の初期化は、非決定性実行パターンにつながり得る。最後に、それぞれのインスタンスは、独立して、実行方法の相対的な重要性を決定し、その場その場でマシンコードをコンパイルするが、これにより、むらがあるアプリケーション性能が引き起こされることが多い。
【０００６】
同時に実行可能なマネージドコードプラットフォームの提供に対する解決策の１つには、マスタプロセスとして実行するマネージドコードプラットフォームの指定が含まれる。個々の子マネージドコードプラットフォームプロセスは、プロセスクローニングを用いて、マスタプロセスから生じ、ランタイム状態をマスタマネージドコードプラットフォームから受け継ぐ。結果として、それぞれの子プロセスは、マスタプロセスによって完了される初期化動作の恩恵を受ける。
【０００７】
初期化動作の正確な選択は、受け継いだランタイム状態がメモリ共有および節約の質、それぞれの子プロセスによって節約される起動およびウォームアップ時間、ならびに、実行決定性が向上するか否かに直接影響するので、重要である。例えば、受け継ぐことができるウォームアップ状態をマスタプロセスコンテキストに構築するように、一般的に用いられる方法がプリコンパイルされるか、クラスローダーが先に呼び出され得る。しかし、子プロセスの性能は、基礎となる実行プロファイルの実際のランタイム条件との一致状態がよくない場合、悪い影響を受け得る。例えば、使用されていない方法がプリコンパイルされるか、または、正しくないクラスがロードされる可能性があり、それにより、方法をコンパイルし、実際に用いられるクラスをロードする必要がある子プロセスにおいて、処理およびメモリリソースが消費される。同様に、デバイス使用パターンは変化し得る。結果として、１つの初期化行動のセットでは、異なる使用および実行シナリオに最も適した、好ましい動作のセットを正しく反映しない可能性があり、観察されたプロファイルデータに基づいて、起動時またはダイナミックにランタイムにおいて細かく調整される必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、ランタイムにおける実際の使用パターンを、特に、マスタランタイムシステムプロセスから受け継がれた、ウォームアップ済み状態に関して、測定するために、クローニングされたランタイムシステムプロセスの実行および性能をプロファイリングする必要がある。このようなアプローチが、マスタランタイムシステムプロセスによって起動時またはランタイムに実行され得る、ダイナミックに適用可能なフィードバックまたは持続的に格納されるプロファイルデータを提供することが好ましい。
【課題を解決するための手段】
【０００９】
（発明の要旨）
マネージドコードプラットフォームは、複数の独立した分離ユーザアプリケーションの発生をサポートするアプリケーションフレームワークにおいて実行される。アプリケーションフレームワークが、書き込み時コピーセマンティクスを用いるユーザアプリケーションのそれぞれのメモリ空間のクローニングをサポートすることが好ましい。マネージドコードプラットフォームは、互換性があるアプリケーションを定義するポータブルコードを解釈する、マスタランタイムシステムプロセス、例えば、バーチャルマシンを含む。アプリケーションマネージャはまた、アプリケーションフレームワーク内で実行し、プロセス間通信メカニズムを介して、マスタランタイムプロセスと通信可能にインターフェースする。アプリケーションフレームワークは、プロセスクローニングを介して、子ランタイムシステムプロセスを作成するように、アプリケーションフレームワークによってリクエストされるときに、マスタランタイムシステムプロセスコンテキストを論理的にコピーする。メモリに格納されたマスタランタイムシステムプロセスのコンテキストは、子ランタイムシステムプロセスによって、ウォームアップ済み状態およびキャッシュ済みコードとして、受け継がれる。書き込み時コピーセマンティクスとともにインプリメントされる場合、プロセスクローニングは、マスタランタイムシステムプロセスコンテキストへの参照の論理コピーを作成する。参照されたマスタランタイムシステムプロセスコンテキストのセグメントは、参照されたコンテキストを変更しようと子ランタイムシステムプロセスによって試みられる場合にのみ、ゆっくりとコピーされる。ランタイムにおいて、子ランタイムシステムプロセスプロファイルのそれぞれは、メモリバッファに一時的にステージされるか、または、ファイルに持続的に格納され得る。アプリケーションマネージャは、インクリメンタルプロファイルデータを取り出し、解析し、マスタウォームアッププログラムを更新する。マスタランタイムシステムプロセスは、初期化のときに、または、アプリケーションマネージャからのコマンドに応答して、コンテキストをダイナミックに再初期化するように、更新されたマスタウォームアッププログラムを実行する。適切なマネージドコードプラットフォームおよびランタイムシステムプロセスの例は、Ｐａｌｏ  Ａｌｔｏ，ＣＡのＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．によってライセンス供与されている、Ｊａｖａ（登録商標）オペレーティング環境およびＪａｖａ（登録商標）バーチャルマシン（ＪＶＭ）アーキテクチャである。
【００１０】
ある実施形態は、プロセスクローニングアプリケーション環境において、インクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングするシステムおよび方法を提供する。マスタランタイムシステムプロセスが実行される。マスタランタイムシステムプロセスのメモリ空間は、プロセスリクエストに応答する子ランタイムシステムプロセスとしてクローニングされる。子ランタイムシステムプロセスが実行される。子ランタイムシステムプロセスの実行は、プロファイリングデータを付加的に収集することによってプロファイリングされる。子ランタイムシステムプロセスプロファイルは、マスタランタイムシステムプロセスにフィードバックされ、後のクローニングされる子ランタイムシステムプロセスが恩恵を受ける。さらなる実施形態において、子ランタイムシステムプロセスプロファイルは、次の起動のときに、マスタランタイムシステムプロセスによって用いられるために、持続性格納装置に保持される。
【００１１】
基礎をなすアプリケーションフレームワークによって提供される、プロセスクローニングメカニズムの使用は、マシンポータブルコードの効率的な同時アプリケーション実行の必要性を解決する以外にもいくつかの利点を提供する。マスタランタイムプロセスコンテキストのクローニングを介して、ウォームアップ済み状態を受け継ぐことは、計算済み、ウォームアップ済み状態をプロセス間で共有することを提供する。同様に、子ランタイムシステムプロセスは、他のプロセスのそれぞれから分離して実行し、それにより、アプリケーションフレームワークのシステムレベルサービスを介して、強いリソース制御が提供される。分離、信頼できるプロセス呼び出しおよび終了、ならびにリソースの再利用が利用可能であり、オペレーティングシステムレベルで、手際よく提供される。さらに、プロセスクローニングは、速いユーザアプリケーション初期化および決定性ランタイム動作を、特に書き込み時コピーセマンティクスを用いるプロセスクローニングを提供する環境について、提供する。最後に、マスタランタイムシステムプロセスコンテキストの非共有セグメントについて、実際のコピーは、書き込み時コピーセマンティクスによって要求されるまで遅らせられ、それにより、セグメントが必要とされる場合、必要とされるまで、アプリケーション性能に影響を与えることが避けられる。
【００１２】
本発明のさらに他の実施形態は、以下の詳細な説明から、当業者にとって容易に明らかになる。詳細な説明においては、本発明を実行するために考えられるベストモードを例示するために、本発明の実施形態が説明される。理解されるように、本発明の精神および範囲から逸脱することなく、本発明は他の異なる実施形態が可能であり、細部のいくつかには様々な明らかな面において変更が為され得る。従って、図面および詳細な説明は、本質的に例示するものであり、限定するものではないとみなされるべきである。
【００１３】
従って、本発明は、以下のものを提供する。
【００１４】
１．プロセスクローニングアプリケーション環境においてインクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングするシステムであって、実行しているマスタランタイムシステムプロセスのメモリ空間を、プロセスリクエストに応答する、子ランタイムシステムプロセスとして、クローニングし、該子ランタイムシステムプロセスを実行する、ランタイム環境と、プロファイリングデータを付加的に収集することによって、該子ランタイムシステムプロセスの実行をプロファイリングする、コレクタとを備える、システム。
【００１５】
２．前記子ランタイムシステムプロセスのメモリ空間に、前記プロファイリングデータを一時的に格納するように、規定される、メモリバッファをさらに備える、項１に記載のシステム。
【００１６】
３．前記ランタイム環境は、前記メモリバッファから、実行しているアプリケーションマネージャプロセスへと、前記プロファイリングデータを周期的に通信する、項２に記載のシステム。
【００１７】
４．前記子ランタイムシステムプロセスにおいて前記アプリケーションマネージャプロセスとともに保持されるプロファイリング実行スレッドと、該アプリケーションマネージャプロセスからのデータリクエストに応答する、該プロファイリング実行スレッドを介して前記プロファイリングデータを提供する応答と、をさらに備える、項３に記載のシステム。
【００１８】
５．前記プロファイリング実行スレッドは、プロセス間通信メカニズムを含む、項４に記載のシステム。
【００１９】
６．前記プロファイリングデータは、前記アプリケーションマネージャプロセスへの通信が完了するときにリセットされる、項３に記載のシステム。
【００２０】
７．デバイスのシャットダウンにおいて、または、周期的に、前記プロファイリングデータを持続的に格納するファイルをさらに備える、項１に記載のシステム。
【００２１】
８．前記ランタイム環境は、前記ファイルから、実行しているアプリケーションマネージャプロセスへと、前記プロファイリングデータを通信する、項７に記載のシステム。
【００２２】
９．オブジェクト指向プログラムコードとして提供され、アプリケーションモデルと関連付けられている、ソース定義からの少なくとも１つのクラスの表現を含むアプリケーションモデルをさらに備えるシステムであって、前記子ランタイムプロセスは、１つのこのようなアプリケーションモデル特有のクラスローダインスタンスを選択し、前記ランタイム環境は、該子ランタイムシステムプロセスによって選択された該アプリケーションモデルを、実行しているアプリケーションマネージャプロセスに通信する、項１に記載のシステム。
【００２３】
１０．前記プロファイリングデータを統合するように、前記プロファイリングデータをオブジェクト指向プログラムコードとして提供されたソース定義として定義されるマスタウォームアッププログラムをさらに備える、項１に記載のシステム。
【００２４】
１１．実行しているアプリケーションマネージャプロセスの実行が終了するときに、前記マスタウォームアッププログラムをファイルに持続的に格納するファイルマネージャをさらに備えるシステムであって、前記ランタイム環境は、前記マスタウォームアッププログラムを該ファイルから取り出し、該マスタウォームアッププログラムを、実行しているさらなるマスタランタイムシステムプロセスのメモリ空間に、解釈し、インスタンス化し、ウォームアップする、項１０に記載のシステム。
【００２５】
１２．前記ランタイム環境は、前記さらなるマスタランタイムシステムプロセスのメモリ空間を、プロセスリクエストに応答する、さらなる子ランタイムシステムプロセスとしてクローニングし、該さらなる子ランタイムシステムプロセスを実行する、項１１に記載のシステム。
【００２６】
１３．前記マスタランタイムシステムプロセスの実行の間、前記マスタウォームアッププログラムをダイナミックに更新するアプリケーションマネージャプログラムをさらに備えるシステムであって、前記ランタイム環境は、該マスタウォームアッププログラムを、該マスタランタイムシステムプロセスのメモリ空間に、解釈し、インスタンス化し、ウォームアップする、項１０に記載のシステム。
【００２７】
１４．前記プロファイリングデータは、クラス初期化、およびダイナミックコンパイルについて選択された方法を含む群から選択されるデータを含む、項１に記載のシステム。
【００２８】
１５．前記マスタランタイムシステムプロセスのメモリ空間を前記子ランタイムシステムプロセス用の別のメモリ空間にコピーすることによって、該子ランタイムシステムプロセスをインスタンス化するプロセスクローニングメカニズムをさらに備える、項１に記載のシステム。
【００２９】
１６．前記マスタランタイムシステムプロセスのメモリ空間への参照を前記子ランタイムシステムプロセス用の別のメモリ空間にコピーすることによって、該子ランタイムシステムプロセスをインスタンス化し、該マスタランタイムシステムプロセスのメモリ空間のコピーを、該子ランタイムシステムプロセスが、該参照されたマスタランタイムシステムプロセスのメモリ空間を変更することを必要とするまで遅らせる、書き込み時コピープロセスクローニングメカニズムをさらに備える、項１に記載のシステム。
【００３０】
１７．前記マスタランタイムシステムプロセスは、前記プロセスリクエストを受け取ることに関連して、スリープ状態にされる、項１に記載のシステム。
【００３１】
１８．前記子ランタイムシステムプロセス上のオペレーティングシステムレベルリソース管理パラメータを設定するリソースコントローラをさらに備える、項１に記載のシステム。
【００３２】
１９．前記オブジェクト指向プログラムコードは、Ｊａｖａ（登録商標）プログラミング言語で書かれている、項１に記載のシステム。
【００３３】
２０．前記マスタランタイムシステムプロセスおよび前記子ランタイムシステムプロセスは、Ｊａｖａ（登録商標）バーチャルマシンである、項１９に記載のシステム。
【発明を実施するための最良の形態】
【００３４】
（発明の詳細な説明）
プロセスクローニングアプリケーション環境において、インクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングするシステムおよび方法が提示される。マスタランタイムシステムプロセスが実行される。マスタランタイムシステムプロセスのメモリ空間は、プロセスリクエストに応答する子ランタイムシステムプロセスとしてクローニングされる。子ランタイムシステムプロセスが実行される。子ランタイムシステムプロセスの実行は、プロファイリングデータを付加的に収集することによってプロファイリングされる。子ランタイムシステムプロセスプロファイルは、マスタランタイムシステムプロセスにフィードバックされ、後のクローニングされる子ランタイムシステムプロセスが恩恵を受ける。さらなる実施形態において、子ランタイムシステムプロセスプロファイルは、次の起動のときに、マスタランタイムシステムプロセスによって用いられるために、持続性格納装置に保持される。
【００３５】
（システム概要）
図１は、例として、複数の異機種デバイス１１上にインプリメントされる、ランタイム環境（ＲＴＥ）１４、２２、２４、および２６を示す機能ブロック図１０である。各異機種デバイス１１は、図２を参照しながら以下に詳細に説明するように、ランタイム環境１４、２１、２４、２６において実行するマネージドコードプラットフォーム、例えば、Ｊａｖａ（登録商標）動作環境などを提供する。異機種デバイス１１は、デスクトップコンピュータシステムまたはラップトップコンピュータシステムなどのクライアントコンピュータシステム１３を、非排他的に含む。各クライアント１３は、格納デバイス１５に動作可能に接続され、データ構造を特定するコードモジュールおよびデータ上で動作する方法のセット、ならびに共有可能なモジュールの集合をそれぞれ定義する、クラス１６およびクラスライブラリ１７のセットを保持する。また、異機種デバイス１１には、携帯情報端末２１を含む携帯用コンピュータデバイスと、携帯電話２３およびセットトップボックス２５などの民生用デバイスとが含まれる。最後に、サーバ１８は、グローバルに共有可能なクラスライブラリ２０が保持される格納デバイス１９に動作可能に接続されている。異機種デバイス１１のそれぞれは、従来のハードワイヤおよびワイヤレスネットワーク構造を含むネットワーク１２を介してインターフェースし得る。他のタイプの異機種デバイス１１ならびに様々なネットワーク構造、配置およびトポロジーが可能である。
【００３６】
各異機種デバイス１１は、リソースを管理し、周辺機器へのアクセスを提供し、メモリリソースを割り当て、プログラム実行および終了を制御するオペレーティングシステムを含む。各オペレーティングシステムは、明記できるプロセスのメモリ空間をクローニングすることによって、複数の独立した、分離ユーザアプリケーションを発生するプロセスクローニングメカニズムをサポートする。本発明における使用に適したプロセスクローニングメカニズムの一例は、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘオペレーティングシステムによって提供されるｆｏｒｋ（）システムコールである。ｆｏｒｋ（）システムコールは、Ｍ．Ｊ．Ｂａｃｈによる「Ｔｈｅ  Ｄｅｓｉｇｎ  Ｏｆ  Ｔｈｅ  Ｕｎｉｘ（登録商標）  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ」（Ｃｈ．７、Ｂｅｌｌ  Ｔｅｌｅ．Ｌａｂｓ．，Ｉｎｃ．（１９８６）に記載されている。この文献の開示内容は、本明細書中、参考として援用される。ｆｏｒｋ（）システムコールを呼び出すプロセスは、親プロセスとして公知であり、新たに作成されるプロセスは子プロセスと呼ばれる。オペレーティングシステムは、別個のプロセス識別子を、別個のプロセスを実行する、子プロセスに割り当てる。オペレーティングプロセスはまた、親プロセスのメモリ空間を子プロセスのメモリ空間にコピーすることによって、親プロセスのコンテキストの論理コピーを作成する。ｆｏｒｋ（）システムコールの書き込み時コピー型の変形例において、オペレーティングシステムは、メモリ空間への参照のみをコピーし、個々のメモリ空間セグメントの実際のコピーを、親プロセスコンテキストの参照されたデータを変更するように子プロセスが試みる場合にそのときまで遅らせる。書き込み時コピーｆｏｒｋ（）システムコールは、書き込み時コピーでないｆｏｒｋ（）システムコールよりも速く、親プロセスと子プロセスとの間で書き込まれていない任意のデータを自動的に共有する。
【００３７】
（付加的にプロファイリングデータをダイナミックにトラッキングするシステム）
図２は、本発明による、プロセスクローニング環境３４において、インクリメンタルプロファイリングをダイナミックかつ持続的にトラッキングするシステムを示すブロック図３０である。システムは、ランタイム環境３１と、マネージドコードプラットフォーム全体の中心を形成する個々のクラス４５およびクラスライブラリ４６とを含む。例として、このシステムは、Ｊａｖａ（登録商標）オペレーティング環境を参照しながら説明されているが、Ｊａｖａ（登録商標）プログラミング言語などのオブジェクト指向プログラミング言語で書かれることが好ましい、アプリケーションを実行する他の形態のマネージドコードプラットフォームが用いられてもよい。
【００３８】
例示的なランタイム環境３１は、アプリケーションマネージャ３２、マスタＪａｖａ（登録商標）バーチャルマシン（ＪＶＭ）プロセス３３、およびゼロ以上のクローニングされたＪＶＭプロセス３４２を含む。マスタＪＶＭプロセス３３およびクローニングされたＪＶＭプロセス３４は、それぞれ、マスタランタイムシステムプロセスおよび子ランタイムシステムプロセスに対応する。マスタランタイムシステムプロセスは、好ましくは、バーチャルマシンとして提供されるが、マシンポータブルコード定義互換性アプリケーションを解釈する。
【００３９】
ランタイム環境３１は、マスタランタイムシステムプロセスのメモリ空間を好ましくはクローニングすることによって、複数の独立した、分離ユーザアプリケーションプロセスインスタンスを発生する、アプリケーションフレームワークを実行する。本発明における使用に適したアプリケーションフレームワークの例は、Ｕｎｉｘ（登録商標）オペレーティングシステムである。そのようなＵｎｉｘ（登録商標）オペレーティングシステムは、全体的に、上記のＭ．Ｊ．Ｂａｃｈの文献のＣｈ．２に記載されており、その開示内容は、本明細書中、参考として援用される。
【００４０】
アプリケーションマネージャ３２は、個々のアプリケーションがそこを通じて選択され、実行され得るユーザインターフェースを提示する。アプリケーションマネージャ３２およびマスタＪＶＭプロセス３３は、プロセス間通信（ＩＰＣ）メカニズム、例えば、パイプまたはソケットを介して通信することが好ましい。マスタＪＶＭプロセス３３は、デバイスブート時に開始される。
【００４１】
初期化において、マスタＪＶＭプロセス３３は、格納デバイス４３から実行可能なプロセスイメージを読み出し、マスタウォームアッププログラム４４において指定されるブートストラップ動作を行う。マスタウォームアッププログラム４４は、クラス４５およびクラスライブラリ４６において定義されたクラスのプリロードと、プリコンパイル方法と、スタテッィクな初期化方法の実行とを含む、あらゆる種類の動作を行い、ウォームアップ動作を指定する実行可能なプログラムである。これらは、それぞれ、同一譲受人に譲渡された、「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｄｙｎａｍｉｃ  Ｐｒｅｌｏａｄｉｎｇ  Ｏｆ  Ｃｌａｓｓｅｓ  Ｔｈｒｏｕｇｈ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」という名称の２００３年１２月２２日に出願された係属中の米国特許出願第１０／７４５，０２３号、「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｐｒｏｖｉｄｉｎｇ  Ｐｒｅｃｏｍｐｉｌｅｄ  Ｃｏｄｅ  Ｔｈｒｏｕｇｈ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」という名称の２００３年１２月２２日に出願された係属中の特許出願第１０／７４５，０２０号、および、「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｅｌｉｍｉｎａｔｉｎｇ  Ｓｔａｔｉｃ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｏｖｅｒｈｅａｄ  Ｂｙ  Ｍｅｍｏｒｙ  Ｓｐａｃｅ  Ｃｌｏｎｉｎｇ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」という名称の２００３年１２月２２日に出願された係属中の特許出願第１０／７４５，０２１号に記載されている。これらの文献は、本明細書中、参考として援用される。従って、初期化の完了において、マスタＪＶＭプロセス３３のメモリイメージは、マスタＪＶＭプロセスコンテキストに格納されている、キークラス、方法および初期化された常態を用いて、初期化され、準備され、ウォームアップされたＪＶＭプロセスのメモリイメージに類似する。
【００４２】
初期化の後、マスタＪＶＭプロセス３３は、アプリケーションマネージャ３２からのさらなる指令を待機しながら、アイドル状態になる。すなわち、イナクティブ状態で「眠る」。マスタＪＶＭプロセス３３は、アプリケーションマネージャ３２から受信したアプリケーションを実行するためのリクエストに応答して起きる。アプリケーションマネージャ３２は、アプリケーション名、クラスパス、およびアプリケーション引数などの標準的なコマンドラインパラメータを含む、リクエストをマスタＪＶＭプロセス３３に送信する。マスタＪＶＭプロセス３３は、基礎となるオペレーティングシステムのプロセスクローニングメカニズムを用いて、マスタＪＶＭプロセス３３の新たなクローニングされたプロセスインスタンスとして、クローニングされたＪＶＭプロセス３４を起こし、作成する。ウォームアップ済み状態３７として、メモリに格納されたマスタＪＶＭプロセス３３のコンテキストは、受け継がれたウォームアップ済み状態４１としてクローニングされたＪＶＭプロセス３４によって受け継がれ、これにより、初期化およびランタイム実行時間が節約され、決定性実行動作が提供される。クローニングされたＪＶＭプロセス３４の「クローニング」に続いて、マスタＪＶＭプロセス３３は、アプリケーション立ち上げリスト５１に立ち上げられたアプリケーションを記録し、イナクティブなスリープ状態に戻る。
【００４３】
書き込み時コピーセマンティクスでインプリメントされる場合、プロセスクローニングは、マスタＪＶＭプロセスコンテキストのみを参照しながら、論理コピーを作成する。参照されたマスタＪＶＭプロセスコンテキストのセグメントは、クローニングされたＪＶＭプロセスによって、参照されたコンテキストを変更しようと試みられる場合にのみ、ゆっくりとコピーされる。従って、クローニングされたＪＶＭプロセスがメモリセグメントに書き込まない限り、セグメントは、親プロセスと子プロセスとの間で共有され続ける。
【００４４】
マスタＪＶＭプロセス３３は、ＩＰＣメカニズムを通じてアプリケーションマネージャ３２から受け取った以下の基本的なコマンドを認識する。
【００４５】
（１）ｌｉｓｔ：アプリケーションマネージャ３２から受け取ったリクエストに応答して立ち上げられるアプリケーションのリストを提供する。
【００４６】
（２）ｊｅｘｅｃ：プロセスクローニングメカニズムを呼び出し、コマンドライン引数を解析し、マスタＪＶＭプロセス３３の新たなインスタンスをクローニングされたＪＶＭプロセス３４として実行する。標準的なＪＶＭプロセスに適合する構文を採用することが好ましい。
【００４７】
（３）ｋｉｌｌ：アプリケーションハンドルまたはプロセス識別子によって識別されるアプリケーションを終了する
（４）ｓｏｕｒｃｅ：引数を解析し、クローニングされたＪＶＭプロセス３４を作成することなくマスタＪＶＭプロセス３３のボディのプログラムを実行する。その後、クローニングされたＪＶＭプロセス３４は、マスタＪＶＭプロセス３３の代わりのソースコマンドの実行から得られる、マスタＪＶＭプロセス３３の精密化されたメモリ状態を受け継ぐ。
【００４８】
他のコマンドも可能である。
【００４９】
デバイスのブート時、マスタＪＶＭプロセス３３は、マスタウォームアッププログラム４４を実行し、ウォームアップ済み状態３７およびコードキャッシュ３８内のコンパイル済み方法コードは、クローニングされたＪＶＭプロセス３４のそれぞれによって、受け継がれたウォームアップ済み状態４１および受け継がれたコードキャッシュ４２内の受け継がれたコンパイル済み方法コードとして、受け継がれる。マスタウォームアッププログラム４４は、以前に実行されたクローニングされたＪＶＭプロセス３４の１つ以上を実行するプロファイルコレクタ３９から以前に引き出され、格納される、持続性プロファイルデータに基づいて、アプリケーションマネージャ３２によって実行される。また、各プロファイルコレクタ３９は、クローニングされたアプリケーションマネージャ３２の１つ以上において実行するプロファイラ４０によって生成されるインクリメンタルプロファイルデータを収集し、格納する。ダイナミックにプロファイルされたデータは、アプリケーションマネージャ３２によって規則的にポーリングされて、マスタダイナミックプロファイル４９が作成され、マスタダイナミックプロファイル４９は、後のクローニングされるＪＶＭプロセス３４が恩恵を受けるように、ソースコマンドを用いて、マスタＪＶＭプロセス３３にフィードバックされる。マスタダイナミックプロファイル４９はまた、次のデバイスブートにおいて、マスタＪＶＭプロセス３３によって用いられ得る、持続性プロファイルの基礎を形成する。
【００５０】
各プロファイラ４０は、当業者であれば理解するように、実行されているアプリケーションアカウンティングを行う。プロファイラ４０は、例えば、アプリケーションにおける重要で、性能感受性があるコードセグメントを識別しようと試みる解釈ループを通じて、アプリケーション実行を連続的に評価する。例として、プロファイラ４０は、ループ反復および方法呼び出しの計算を含み、実行方法をサンプリングすることによる、アカウンティングを通じて、方法呼び出しおよびシステムライブラリコールを識別する。アカウンティグを行うために、他の形態およびアプローチも可能である。プロファイラ４０が、プロファイリングを通じて収集されたデータに閾値を付与し、閾値を越える方法を識別することが好ましい。プロファイルコレクタ３９は、プロファイラ４０によって行われた動作を評価し、性能に影響を与えるイベント、例えば、クラス初期化およびダイナミックコンパイルについて選択された方法を、プロファイルデータとして格納する。他のタイプおよび形態のプロファイルデータも可能である。
【００５１】
ある実施形態において、クローニングされたＪＶＭプロセス３４のそれぞれのプロファイルコレクタ３５は、収集されたプロファイルデータを、一時的にメモリバッファ５２に格納する。クローニングされたＪＶＭプロセス３４のそれぞれは、メインの実行スレッド（図示せず）と同時に実行するプロファイルリクエスト待ち受けスレッド（図示せず）を保持する。アプリケーションマネージャ３２は、ソケットなどの適切なＩＰＣメカニズムを用いて、プロファイルリクエスト待ち受けスレッドにアクセスする。ランタイムにおいて、クローニングされるＪＶＭプロセス３４は、アプリケーションマネージャ３２がそこを通じてポーリングリクエストなどのプロファイリングデータクエリを周期的に送信する、プロファイルスレッドを待ち受ける。それに応答して、クローニングされるＪＶＭプロセス３４は、インクリメンタルプロファイルデータをアプリケーションマネージャ３２に送信し、メモリバッファ５２をリセットする。最後のプロファイリングデータクエリ以来付加的に収集されたプロファイルデータのみが、メモリバッファ５２においてステージされ、アプリケーションマネージャ３２は、マスタダイナミックプロファイル４９におけるインクリメンタルプロファイルデータの類似するセットを格納する。
【００５２】
さらなる実施形態において、各クローニングされたＪＶＭプロセス３４のそれぞれのプロファイルコレクタ３５は、格納されたプロファイル４８として、持続的に、収集されたプロファイルデータを格納する。ランタイムにおいて、アプリケーションマネージャ３２は、格納されたプロファイル４８におけるインクリメンタルプロファイルデータを、好ましくは、周期的に、重要なイベントについて繰り返し、評価されたインクリメンタルプロファイルデータをマスタダイナミックプロファイルに格納する。インクリメンタルプロファイルデータはまた、メモリバッファ５２に一時的プロファイルデータとして、格納されたプロファイル４８に持続性プロファイルデータとして格納され得る。
【００５３】
ランタイムにおいて、アプリケーションマネージャ３２は、それぞれのクローンされたＪＶＭプロセス３２から受け取ったインクリメンタルプロファイルデータに類似する、マスタダイナミックプロファイル４９を保持する。マスタダイナミックプロファイル４９は、観察された重要なイベント、例えば、クラス初期化、およびダイナミックコンパイルについて選択された方法などをダイナミックに反映する。このデータは、ランタイムにおける実際の使用パターンを反映させるように、マスタＪＶＭプロセス３３によって初期化の際に実行される、ウォームアップ初期化行動の微調整に用いられ得る。従って、アプリケーションマネージャ３２は、マスタダイナミックプロファイル４９を解析し、マスタウォームアッププログラム４４を更新する。ある実施形態において、アプリケーションマネージャ３２は、マスタウォームアッププログラム４４を、ファイルとして、格納デバイス４３に、デバイスの停止時または周期的に、例えば、自動セーブ機能に応答して、持続的に格納する。その後、デバイスブート時において、マスタＪＶＭプロセス３３は、最新の観察された使用パターンを反映する、セーブされたマスタウォームアッププログラム４４を実行する。その後、ウォームアップ済み状態３７およびコードキャッシュ３８内のコンパイル済み方法コードは、それぞれのクローニングされたＪＶＭプロセス３４によって、受け継がれたウォームアップ済み状態４１および受け継がれたコードキャッシュ４２内の受け継がれたコンパイル済み方法コードとして受け継がれる。
【００５４】
さらなる実施形態において、アプリケーションマネージャ３２は、インクリメンタルプロファイルデータをマスタＪＶＭプロセス３３にダイナミックにフィードする。マスタＪＶＭプロセス３３は、ＩＰＣメカニズムを通じてアプリケーションマネージャ３２から受け取ったさらなる基本的なソースコマンドを認識する。このようなソースコマンドは、同一譲受人に譲渡された、「Ｓｙｓｔｅｍ  Ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｐｅｒｆｏｒｍｉｎｇ  Ｉｎｃｒｅｍｅｎｔａｌ  Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｏｆ  Ａ  Ｍａｓｔｅｒ  Ｒｕｎｔｉｍｅ  Ｓｙｓｔｅｍ  Ｐｒｏｃｅｓｓ」という名称の２００３年１２月２２日に出願された係属中の米国特許出願第１０／７４５，１６４号に記載されている。この出願の開示内容は、本明細書中で援用される。簡潔に言うと、マスタＪＶＭプロセス３３上で、ソースコマンドを実行することは、ウォームアップ状態、すなわち、ウォームアップ済み状態３７およびコードキャッシュ３８が、付加的に初期化されることを可能にする。アプリケーションマネージャ３２は、マスタウォームアッププログラム４４を、マスタＪＶＭプロセス３３のコンテキストを精密化するために実行された、ソースコマンドを用いて、マスタＪＶＭプロセス３３に送る。その後発生したクローニングされたＪＶＭプロセス３３のそれぞれは、その時点でウォームアップされたコンテキストを、そのときまでにマスタＪＶＭプロセス３３によって実行される、受け継がれたウォームアップ済み状態４３およびコードキャッシュ３８として受け継ぐ。
【００５５】
（マスタＪＶＭプロセスマッピング）
図３は、例として、メモリ６２にマッピングされるマスタＪＶＭプロセス３３を示すブロック図６０である。概して、実行するプロセスのコンテキストには、データ空間、ユーザスタック、カーネルスタック、ならびに、オープンファイル、現在のディレクトリ、および監視許可設定をリスト化するユーザ領域が含まれる。他のタイプのコンテキストも提供され得る。コンテキストは、オペレーティングシステムによって、メモリ６２に格納され、管理される。デバイスブート時において、オペレーティングシステムは、おそらくは、連続していないページ６４ａ〜ｄにおいて、実行可能なマスタＪＶＭプロセス３３をメモリ６２にインスタンス化し、マスタＪＶＭプロセス３３の実行を開始する前に、メモリ空間の割り当てをページテーブルエントリ６３としてページテーブル６１に記録する。また、マスタＪＶＭプロセスコンテキストは、プロセスクローニング、特に、コピーオンライトセマンティクスでのプロセスクローニングに適合する、他のメモリ管理システムを用いて、例えば、デマンドページング、スワッピング、および類似のプロセスメモリ割り当て方式を用いて、同様にマッピングされ得る。
【００５６】
（クローニングされたＪＶＭマッピング）
図４は、例として、メモリ空間クローニングを介して、メモリ６２にマッピングされた、マスタＪＶＭプロセス３３およびクローニングされたＪＶＭプロセス３４を示すブロック図７０である。書き込み時コピーセマンティクスを提供しないプロセスクローニングを用いるシステムにおいて、親プロセスコンテキストを格納する、メモリ６２内のページ６４ａ〜ｃの物理的コピーは、子プロセスのそれぞれについて作成される。プロセスクローニングリクエストに応答して、オペレーティングシステムは、クローニングされたＪＶＭプロセス３４について、実行可能なマスタＪＶＭプロセス３３の表現のコピーを、メモリ６２に、おそらくは、非連続的なページ７２ａ〜ｄにおいて、インスタンス化し、クローニングされたＪＶＭプロセス３４の実行を開始する前に、メモリ空間の割り当てを、ページテーブルエントリ７１として、ページテーブル６１に記録する。従って、クローニングされたＪＶＭプロセス３４は、マスタＪＶＭプロセス３３のコンテキストの物理的コピーを用いて作成される。新たな別のマスタＪＶＭプロセスコンテキストの物理的コピーが作成されるので、クローニングされたＪＶＭプロセス３４は、ウォームアップ済み状態３７を受け継ぎ、マスタＪＶＭプロセス３３のプリロード済みクラスを含む。しかし、ランタイム環境３１のメモリフットプリント全体は、マスタＪＶＭプロセスコンテキストのさらなるコピーを格納するために必要とされるメモリ空間の分、増大される。
【００５７】
（書き込み時コピーを用いるクローニングされたＪＶＭプロセスマッピング）
図５Ａ〜５Ｂは、例として、書き込み時コピーセマンティクスを用いるメモリ空間クローニングを介して、メモリ６２にマッピングされた、マスタＪＶＭプロセス３３およびクローニングされたＪＶＭプロセス３４を示すブロック図８０および９０である。書き込み時コピーセマンティクスを提供するプロセスクローニングを用いるシステムにおいて、親プロセスコンテキストを格納するメモリ空間への参照、代表的には、ページテーブルエントリのコピーのみが、子プロセスのそれぞれについて作成される。まず、図５Ａを参照すると、プロセスクローニングリクエストに応答して、オペレーティングシステムは、実行可能なマスタＪＶＭプロセス３３のメモリ空間を参照するページテーブルエントリ６３のみを、クローニングされたＪＶＭプロセス３４用の新たなページテーブルエントリ８１のセットとしてコピーする。従って、クローニングされたＪＶＭプロセス３４は、マスタＪＶＭプロセス３４と、マスタＪＶＭプロセスコンテキストを格納する、おそらくは非連続的なページ６４ａ〜ｄへの同じ参照を用いる。クローニングされたＪＶＭプロセス３４に関連付けられたアプリケーションの初期化および実行が必要とする時間は、ページテーブルエントリ６２のみがマスタＪＶＭプロセスコンテキストをクローニングするためにコピーされるので、より短い。さらに、クローニングされたＪＶＭプロセス３４がマスタＪＶＭプロセスコンテキストを変更しようとするまで、メモリ空間は、他のプロセスが共有することができる、読み出し専用データとして扱われる。
【００５８】
次に、図５Ｂを参照すると、クローニングされたＪＶＭプロセス３４は、マスタＪＶＭプロセスコンテキストのメモリ空間において、ページ８２ｃのうちの１つを変更しようと試みる。応答して、オペレーティングシステムは、変更されるメモリ空間ページ８２ｃの物理的コピーを新たなページ９１として作成し、クローニングされたＪＶＭプロセス３４について、ページテーブルエントリ８１における割り当てを更新する。書き込み時コピーセマンティクスを介して、ランタイム環境３１のフットプリント全体は、可能な限り小さいままにされ、クローニングされたＪＶＭプロセス３４のそれぞれが、アプリケーション特有コンテキストについて、さらなるメモリ空間を必要とする場合、実際に必要とするまで成長するのみである。
【００５９】
（付加的にプロファイリングデータをダイナミックにトラッキングする方法）
図６は、本発明による、プロセスクローニングアプリケーション環境において、インクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングする方法１００を示すフローチャートである。方法１００は、例えば、図２のランタイム環境３１または他のコンポーネントによって実行され得る、一連のプロセス動作またはステップとして記載される。
【００６０】
最初に、アプリケーションマネージャ３２がロードされる（ブロック１０１）。デバイスのブート時に、マスタＪＶＭプロセス３３がロードされ、初期化される（ブロック１０２）。詳細については、図７を参考しながら下記に記載する。ローディングおよび初期化に続いて、マスタＪＶＭプロセス３３は、イナクティブスリープモードになる（ブロック１０３）。アプリケーションマネージャ３２からのリクエストを受け取ると（ブロック１０４）、マスタＪＶＭプロセス３３は起きる（ブロック１０５）。必要とされる場合、アプリケーションマネージャ３２について、ネットワーク接続識別子（ＩＤ）をチェックし（ブロック１０６）、リクエストのタイプを判別する（ブロック１０７）。マスタＪＶＭプロセス３３は、図２を参照しながら上記で説明したコマンドｌｉｓｔ、ｊｅｘｅｃ、ｓｏｕｒｃｅ、ｋｉｌｌを識別する。リクエストタイプがｓｏｕｒｃｅコマンドに対応する場合、マスタＪＶＭプロセス３３にマスタウォームアッププログラム４４を実行するように命令する（ブロック１０８）。マスタＪＶＭプロセス３３は、マスタＪＶＭプロセス３３から発生した後でクローニングされるＪＶＭプロセス３４が精密化されたコンテキストを受け継ぐように、マスタＪＶＭプロセス３３のウォームアップ済み状態を精密化または「向上」させるマスタウォームアッププログラム４４を実行する（ブロック１０９）。リクエストタイプがｊｅｘｅｃコマンドに対応する場合、マスタＪＶＭプロセス３３にプロセスクローニングを介してアプリケーションの実行を開始するように命令する（ブロック１１０）。クローニングされたＪＶＭプロセス３４は、クローニングされ、実行される（ブロック１１１）。詳細については、図８および９を参照しながら下記に説明する。
【００６１】
同時に、アプリケーションマネージャ３２は、メモリバッファ５２または格納されたプロファイル４８からプロファイルデータを収集する（ブロック１１２）。各プロファイルコレクタ３９は、１つ以上のクローニングされたＪＶＭプロセス３４において実行するプロファイラ４０によって生成されるインクリメンタルプロファイルデータを収集し、格納する。ダイナミックにプロファイルされるデータは、アプリケーションマネージャ３２によって規則的にポーリングされ、マスタダイナミックプロファイル４９が生成され、ｓｏｕｒｃｅコマンドを用いてマスタＪＶＭプロセス３３にフィードバックされて（ブロック１０８）、後のクローニングされるＪＶＭプロセス３４が恩恵を受ける。従って、マスタＪＶＭプロセス３３は、インクリメンタルプロファイルデータ（ブロック１１３）のフィードバックを介して更新され、アプリケーションマネージャ３２は、ｓｏｕｒｃｅコマンドを送信することによってマスタＪＶＭプロセス状態をウォームアップする（ブロック１１４）。マスタダイナミックプロファイル４９はまた、次のデバイスブートのときにマスタＪＶＭプロセス３３によって用いられることができる持続性プロファイルの基礎を形成する。持続的に保持される場合（ブロック１１５）、マスタダイナミックプロファイル４９は、例えばファイルにおいて、持続的に格納される（ブロック１１６）。処理は、アプリケーションマネージャ３２、マスタＪＶＭプロセス３３、およびランタイム環境３１が終了されるまで無期限に続けられる。
【００６２】
（マスタＪＶＭプロセスをローディングするルーチン）
図７は、図６の方法１００において用いられる、マスタＪＶＭプロセス３３をローディングするルーチン１２０を示すフローチャートである。このルーチンの目的の１つは、マスタＪＶＭプロセス３３を呼び出し、クローニングされたＪＶＭプロセス３４によって受け継がれるようにマスタＪＶＭプロセス状態をウォームアップすることである。
【００６３】
最初に、マスタＪＶＭプロセス３３は、デバイスブート時において、実行を開始する（ブロック１２１）。マスタＪＶＭプロセス３３は、マスタウォームアッププログラム４４およびマスタダイナミックプロファイル４９を用いて、２組のウォームアップ動作を実行する。マスタウォームアッププログラム４４はスタティックであり、デバイスのブートの間で変化を生じさせないのに対し、マスタダイナミックプロファイル４９は、アプリケーションマネージャ３２によって収集され、適合されたインクリメンタルプロファイルデータに基づく連続的な変化の影響を受ける。まず、マスタＪＶＭプロセス３３はマスタウォームアッププログラム４４を実行して、マスタＪＶＭプロセスコンテキストに格納されるキークラス、方法および初期化状態を用いて、初期化され、準備され、ウォームアップされたＪＶＭプロセスのメモリイメージに類似するメモリイメージが、形成される（ブロック１２２）。第２に、アプリケーションマネージャ３２がマスタダイナミックプロファイル４９を持続的に保持する場合（ブロック１２３）、マスタＪＶＭプロセス３３は、マスタダイナミックプロファイル４９を取り出し、実行する（ブロック１２４）。その後、マスタＪＶＭプロセス３３は、任意の他のウォームアップ動作を完了し（ブロック１２５）、ルーチンは戻る。
【００６４】
（書き込み時コピーがないプロセスクローニングのルーチン）
図８は、図６の方法１００において用いられる、書き込み時コピーがないプロセスをクローニングするルーチン１３０を示すフローチャートである。このルーチンの目的の１つは、書き込み時コピーセメンティクスを提供しないプロセスクローニングを介して、クローニングされたＪＶＭプロセス３４の実行を作成し、開始させることである。
【００６５】
最初に、マスタＪＶＭプロセス３３のコンテキストを含むメモリ空間は、クローニングされたＪＶＭプロセス３４について、新たなメモリ空間に物理的にコピーされる（ブロック１３１）。必要に応じて、マスタＪＶＭプロセス３３は、クローニングされたＪＶＭプロセス３４にわたって、オペレーティングシステムレベルリソース管理パラメータを設定し得る（ブロック１３２）。これには、優先度のスケジューリングならびにプロセッサおよびメモリ消費の制限を設定することが含まれる。他のタイプのリソース管理制御も可能である。その後、クローニングされたＪＶＭプロセス３４は、複製されたマスタＪＶＭプロセスコンテキストを用いて、ランタイム環境３１によって実行される（ブロック１３３）。実行の間、クローニングされたＪＶＭプロセス３４は、アプリケーションをプロファイリングして、インクリメンタルプロファイルデータを作成する（ブロック１３４）。インクリメンタルプロファイルデータが持続的に格納される場合（ブロック１３５）、クローニングされたＪＶＭプロセス３４は、格納されたプロファイル４８として、インクリメンタルプロファイルデータを格納する（ブロック１３６）。そうでない場合、インクリメンタルプロファイルデータは、メモリバッファ５２に一時的にステージされる（ブロック１３７）。ルーチンは、クローニングされたＪＶＭプロセス３４が完了するときに、戻る（ブロック１３８）。
【００６６】
（書き込み時を用いるプロセスクローニングのルーチン）
図９は、図６の方法１００において用いられる、書き込み時コピーを用いるプロセスをクローニングするルーチン１４０を示すフローチャートである。このルーチンの目的の１つは、書き込み時コピーを提供するプロセスクローニングを介して、クローニングされたＪＶＭプロセス３４の実行を作成し、開始することである。
【００６７】
最初に、クローニングされたＪＶＭプロセス３４について、マスタＪＶＭプロセス３３のコンテキストを含むメモリ空間への参照がコピーされる（ブロック１４１）。必要に応じて、マスタＪＶＭプロセス３３は、クローニングされたＪＶＭプロセス３４にわたって、オペレーティングシステムレベルリソース管理パラメータを設定し得る（ブロック１４２）。これには、優先度のスケジューリングならびにプロセッサおよびメモリ消費の制限を設定することが含まれる。他のタイプのリソース管理制御も可能である。その後、クローニングされたＪＶＭプロセス３４は、参照されたマスタＪＶＭプロセスコンテキストを用いて、ランタイム環境３１によって実行される（ブロック１４３）。実行の間、クローニングされたＪＶＭプロセス３４は、アプリケーションをプロファイリングし、インクリメンタルプロファイルデータを作成する（ブロック１４４）。インクリメンタルプロファイルデータが持続的に格納される場合（ブロック１４５）、クローニングされたＪＶＭプロセス３４は、格納されたプロファイル４８として、インクリメンタルプロファイルデータを格納する。そうでない場合、インクリメンタルプロファイルデータは、メモリバッファ５２に一時的にステージされる（ブロック１４７）。クローニングされたＪＶＭプロセス３４が、マスタＪＶＭプロセスコンテキストへと参照されるメモリ空間に書き込もうとするたび（ブロック１４８）、オペレーティングシステムは、適用可能なメモリセグメントをコピーする（ブロック１４９）。そうでない場合、クローニングされたＪＶＭプロセス３４は、読み出し専用データとして扱われる、参照されたマスタＪＶＭプロセスコンテキストを用い続ける（ブロック１５０）。ルーチンは、クローニングされたＪＶＭプロセス３４が完了するときに、戻る（ブロック１５１）。
【００６８】
本発明は、特に、上記の実施形態を参照して例示および説明されてきたが、当業者であれば、形態および細部における上記および他の変更は、本発明の精神および範囲から逸脱することなく為され得ることを理解する。
【図面の簡単な説明】
【００６９】
【図１】図１は、例として、複数の異機種デバイス上にインプリメントされる、ランタイム環境を示す機能ブロック図である。
【図２】図２は、本発明による、プロセスクローニング環境において、インクリメンタルプロファイリングをダイナミックかつ持続的にトラッキングするシステムを示すブロック図である。
【図３】図３は、例として、メモリにマッピングされるマスタＪＶＭプロセスを示すブロック図である。
【図４】図４は、例として、メモリ空間クローニングを介して、メモリにマッピングされた、マスタＪＶＭプロセスおよびクローニングされたＪＶＭプロセスを示すブロック図である。
【図５Ａ】図５Ａは、例として、書き込み時コピーセマンティクスを用いるメモリ空間クローニングを介して、メモリにマッピングされた、マスタＪＶＭプロセスおよびクローニングされたＪＶＭプロセスを示すブロック図である。
【図５Ｂ】図５Ｂは、例として、書き込み時コピーセマンティクスを用いるメモリ空間クローニングを介して、メモリにマッピングされた、マスタＪＶＭプロセスおよびクローニングされたＪＶＭプロセスを示すブロック図である。
【図６】図６は、本発明による、プロセスクローニングアプリケーション環境において、インクリメンタルプロファイリングデータをダイナミックかつ持続的にトラッキングする方法を示すフローチャートである。
【図７】図７は、図６の方法において用いられる、マスタＪＶＭプロセスをローディングするルーチンを示すフローチャートである。
【図８】図８は、図６の方法において用いられる、書き込み時コピーがないプロセスをクローニングするルーチンを示すフローチャートである。
【図９】図９は、図６の方法において用いられる、書き込み時コピーを用いるプロセスをクローニングするルーチンを示すフローチャートである。
【図１】
2005216288.tif 000003
【図２】
2005216288.tif 000004
【図３】
2005216288.tif 000005
【図４】
2005216288.tif 000006
【図５Ａ】
2005216288.tif 000007
【図５Ｂ】
2005216288.tif 000008
【図６】
2005216288.tif 000009
【図７】
2005216288.tif 000010
【図８】
2005216288.tif 000011
【図９】
2005216288.tif 000012
【外国語明細書】
1. Title of Invention
System and Method for Dynamically and persistently tracking incremental profiling data in a process cloning application environment
2. Detailed Description of Invention
FIELD OF THE INVENTION
The invention relates in general to tracking profiling data and, in particular, to a system and method for dynamically and persistently tracking incremental profiling data in a process cloning application environment.
BACKGROUND OF THE INVENTION
Recent advances in microprocessor design and component integration have enabled a wide range of devices to offer increasingly complex functionality and “soft” features.  Soft features include software applications that enhance and customize the operation of a device.  These devices include standard computing devices, such as desktop and laptop computers, portable computing devices, such as personal data assistants, and consumer devices, such as cellular telephones, messaging pagers, gaming consoles, and set top boxes.  Most devices now include an operating system to support the soft features and other extensions.
The increased capabilities offered by these software-upgradeable devices have also created certain user expectations.  Often, users are not technically savvy and are intolerant of performance compromises occasioned by architectural challenges, such as slow or inconsistent application performance.  Similarly, users generally expect to be able to access a host of separate applications, which are implemented at the system level through multitasking.  For users, widely available software applications assure a positive experience through consistency and increased exposure across multiple platforms.  However, for software developers, engineering software applications for disparate computing platforms entails increased development costs and on-going support and upgrade commitments for each supported architecture.
Managed code platforms provide one solution to software developers seeking to support multiple platforms by presenting a machine-independent and architecture-neutral operating environment.  Managed code platforms include programming language compilers and interpreters executed by an operating system as user applications, but which provide virtual runtime environments within which compatible applications can operate.  For instance, applications written in the Java programming language, when combined with a Java virtual machine (JVM) runtime environment, can operate on heterogeneous computer systems independent of machine-specific environment and configuration settings.  An overview of the Java programming language is described in P. van der Linden, “Just Java,” Ch. 1, Sun Microsystems, Inc. (2d ed. 1997), the disclosure of which is incorporated by reference.  JVMsare a critical component to the overall Java operating environment, which can be ported to the full range of computational devices, including memory-constrained consumer devices.
Managed code platforms are generally designed for the monotonic execution of a single application instance.  Multiple instances of a managed code platform are executed to simulate multitasking behavior.  Such forced concurrency, however, creates several performance problems.  First, each instance incurs a startup transient.  Executable and startup data must be read from slow persistent storage, which results in slow initial application performance.  Similarly, memory is not shared between instances and each additional instance increases the overall memory footprint of the platform by separately loading and instantiating classes, generally problematic in memory-constrained systems.  Moreover, data dependencies and deferred initialization of system state can result in non-deterministic execution patterns.  Finally, each instance independently determines the relative importance of executing methods and compiles machine code on an ad hoc basis, often causing inconsistent application performance.
One solution to providing concurrently executable managed code platforms involves designating a managed code platform that executes as a master process.  Individual child managed code platform processes are spawned from the master process using process cloning and inherit runtime state from the master managed code platform.  As a result, each child process benefits from the initialization actions completed by the master process.
Accurately selecting the initialization actions is important since the inherited runtime state directly affects the quality of memory sharing and savings, startup and warmuptimes saved by each child process, and whether execution determinism is improved.  In one approach, initialization actions are chosen to improve child process performance by initializing the runtime state based on a priori knowledge of likely execution profile.  For instance, commonly used methods can be precompiled or class loaders preemptively invoked to build inheritable, warmup state into the master process context.  However, child process performance could be adversely affected if the underlying execution profile is poorly matched to real runtime conditions.  For example, unused methods could be precompiled or incorrect classes could be loaded, thereby consuming processing and memory resources in the child process, which must also compile the methods and load the classes actually used.  Similarly, the device usage patterns could change.  As a result, a single set of initialization actions could inaccurately reflect the preferable set of actions best suited for different usage and execution scenarios and should instead be fine tuned either at startup or dynamically at runtime based on observed profile data.
Therefore, there is a need for profiling the execution and performance of cloned runtime system processes to measure actual usage patterns at runtime, particularly relative to prewarmedstate inherited from a master runtime system process.  Preferably, such an approach would provide dynamically applicable feedback or persistently stored profile data, which could be executed by a master runtime system process at startup or runtime.
SUMMARY OF THE INVENTION
A managed code platform is executed in an application framework that supports the spawning of multiple and independent isolated user applications.  Preferably, the application framework supports the cloning of the memory space of each user application using copy-on-write semantics.  The managed code platform includes a master runtime system process, such as a virtual machine, to interpret machine-portable code defining compatible applications.  An application manager also executes within the application framework and is communicatively interfaced to the master runtime system process through an inter-process communication mechanism.  The application framework logically copies the master runtime system process context upon request by the application framework to create a child runtime system process through process cloning.  The context of the master runtime system process stored in memory is inherited by the child runtime system process as prewarmed state and cached code.  When implemented with copy-on-write semantics, the process cloning creates a logical copy of references to the master runtime system process context.  Segments of the referenced master runtime system process context are lazily copied only upon an attempt by the child runtime system process to modify the referenced context.  At runtime, each child runtime system process profiles an application to create incremental profile data, which can be transiently staged in a memory buffer or persistently stored in a file.  The application manager retrieves and analyzes the incremental profile data and updates a master warmupprogram.  The master runtime system process executes the updated master warmup program either upon initialization or in response to a command from the application manager to dynamically reinitialize the context.  An example of a suitable managed code platform and runtime system process are the Java operating environment and Java virtual machine (JVM) architecture, as licensed by Sun Microsystems, Inc., Palo Alto, CA.  
One embodiment provides a system and method for dynamically and persistently tracking incremental profiling data in a process cloning application environment.  A master runtime system process is executed.  A memory space of the master runtime system process is cloned as a child runtime system process responsive to a process request.  The child runtime system process is executed.  The execution of the child runtime system process is profiled by collecting profiling data incrementally.  The child runtime system process profiles are fed back to the master runtime system process to benefit subsequent cloned child runtime system processes.  In a further embodiment, the child runtime system process profiles are maintained in a persistent storage for use by the master runtime system process upon the next start up.
The use of the process cloning mechanism provided by the underlying application framework provides several benefits in addition to resolving the need for efficient concurrent application execution of machine portable code.  The inheritance of prewarmed state through the cloning of the master runtime process context provides inter-process sharing of pre-computed, pre-warmed state.  Similarly, each child runtime system process executes in isolation of each other process, thereby providing strong resource control through the system level services of the application framework.  Isolation, reliable process invocation and termination, and resource reclamation are available and cleanly provided at an operating system level.  In addition, process cloning provides fast user application initialization and deterministic runtime behavior, particularly for environments providing process cloning with copy-on-write semantics.  Finally, for non-shareable segments of the master runtime system process context, actual copying is deferred until required through copy-on-write semantics, which avoids impacting application performance until, and if, the segment is required.
Still other embodiments of the invention will become readily apparent to those skilled in the art from the following detailed description, wherein are described embodiments of the invention by way of illustrating the best mode contemplated for carrying out the invention.  As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the invention.  Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
Accordingly, the present invention provides the following items:
1. A system for dynamically and persistently tracking incremental profiling data in a process cloning application environment, comprising:
a runtime environment to clone a memory space of an executing master runtime system process as a child runtime system process responsive to a process request and executing the child runtime system process; and
a collector to profile the execution of the child runtime system process by collecting profiling data incrementally.
2. A system according to Item 1, further comprising:
a memory buffer defined in a memory space of the child runtime system process to store the profiling data transiently.
3. A system according to Item 2, wherein the runtime environment communicates the profiling data periodically from the memory buffer to an executing application manager process.
4. A system according to Item 3, further comprising:
a profiling execution thread maintained with the application manager process in the child runtime system process; and
a response to provide the profiling data via the profiling execution thread responsive to a data request from the application manager process.
5. A system according to Item 4, wherein the profiling execution thread comprises an inter-process communication mechanism.
6. A system according to Item 3, wherein the profiling data is reset upon completing the communication to the application manager process.
7. A system according to Item 1, further comprising:
a file to store the profiling data persistently at device shutdown or on a periodic basis.
8. A system according to Item 7, wherein the runtime environment communicates the profiling data from the file to an executing application manager process.
9. A system according to Item 1, further comprising:
an application model comprising a representation of at least one class from a source definition provided as object-oriented program code and associated with the application model, wherein the child runtime process selects one such application model specific class loader instance and the runtime environment communicates the application model selected by the child runtime system process to an executing application manager process.
10. A system according to Item 1, further comprising:
a master warmup program defined as a source definition provided as object-oriented program code to consolidate the profiling data.
11. A system according to Item 10, further comprising:
a file manager to store the master warmup program persistently in a file upon termination of the execution of an executing application manager process, wherein the runtime environment retrieves the master warmupprogram from the file, and interprets, instantiates and warms up the master warmup program into a memory space of an executing further master runtime system process.
12. A system according to Item 11, wherein the runtime environment clones the memory space of the further master runtime system process as a further child runtime system process responsive to a process request and executing the further child runtime system process.
13. A system according to Item 10, further comprising:
an application manager program to dynamically update the master warmupprogram during execution of the master runtime system process, wherein the runtime environment interprets, instantiates and warms up the master warmup program into the memory space of the master runtime system process.
14. A system according to Item 1, wherein the profiling data comprises data selected from the group comprising class initializations, and methods selected for dynamic compilation.
15. A system according to Item 1, further comprising:
a process cloning mechanism to instantiate the child runtime system process by copying the memory space of the master runtime system process into a separate memory space for the child runtime system process.
16. A system according to Item 1, further comprising:
a copy-on-write process cloning mechanism to instantiate the child runtime system process by copying references to the memory space of the master runtime system process into a separate memory space for the child runtime system process, and to defer copying of the memory space of the master runtime system process until the child runtime system process needs to modify the referenced memory space of the master runtime system process.
17. A system according to Item 1, wherein the master runtime system process is caused to sleep relative to receiving the process request.
18. A system according to Item 1, further comprising:
a resource controller to set operating system level resource management parameters on the child runtime system process.
19. A system according to Item 1, wherein the object-oriented program code is written in the Java programming language.
20. A system according to Item 19, wherein the master runtime system process and the child runtime system process are Java virtual machines.
DETAILDEDDESCRIPTION OF THE INVENTION
A system and method for dynamically and persistently tracking incremental profiling data in a process cloning application environment is presented.  A master runtime system process is executed.  A memory space of the master runtime system process is cloned as a child runtime system process responsive to a process request.  The child runtime system process is executed.  The execution of the child runtime system process is profiled by collecting profiling data incrementally.  The child runtime system process profiles are fed back to the master runtime system process to benefit subsequent cloned child runtime system processes.  In a further embodiment, the child runtime system process profiles are maintained in a persistent storage for use by the master runtime system process upon the next start up.
System Overview
FIGURE 1 is a functional block diagram 10 showing, by way of example, runtime environments (RTEs) 14, 22, 24, 26 implemented on a plurality of heterogeneous devices 11.  Each heterogeneous device 11 provides a managed code platform, such as the Java operating environment, executing in a runtime environment 14, 21, 24, 26, as further described below with reference to FIGURE 2.  The heterogeneous devices 11 include, nonexclusively, a client computer system 13, such as a desktop or laptop computer system.  Each client 13 is operatively coupled to a storage device 15 and maintains a set of classes 16 and class libraries 17, which respectively define code modules that specify data structures and sets of methods that operate on the data, and shareable collections of the modules.  The heterogeneous devices 11 also include portable computing devices, including personal data assistants 21, and consumer devices, such as cellular telephones 23 and set top boxes (STB) 25.  Finally, a server 18 is operatively coupled to a storage device 19 in which globally shareable class libraries 20 are maintained.  Each of the heterogeneous devices 11 can interface via a network 12, which includes conventional hardwired and wireless network configurations.  Other types of heterogeneous devices 11 and various network configurations, arrangements, and topologies are possible.
Each heterogeneous device 11 includes an operating system to manage resources, provide access to peripheral devices, allocate memory resources, and control program execution and termination.  Each operating system supports a process cloning mechanism that spawns multiple and independent isolated user applications by cloning the memory space of specifiable processes.  An example of a process cloning mechanism suitable for use in the present invention is the fork() system call provided by the Unix or Linux operating systems, such as described in M.J. Bach, “The Design Of The Unix Operating System,” Ch. 7, Bell Tele. Labs., Inc. (1986), the disclosure of which is incorporated by reference.  The process invoking the fork()system call is known as the parent process and the newly created process is called the child process.  The operating system assigns a separate process identifier to the child process, which executes as a separate process.  The operating system also creates a logical copy of the context of the parent process by copying the memory space of the parent process into the memory space of the child process.  In a copy-on-write variant of the fork() system call, the operating system only copies references to the memory space and defers actually copying individual memory space segments until, and if, the child process attempts to modify the referenced data of the parent process context.  The copy-on-write fork() system call is faster than the non-copy-on-write fork() system call and implicitly shares any data not written into between the parent and child processes.
System for Dynamically Tracking Profiling Data Incrementally
FIGURE 2 is a block diagram 30 showing a system for dynamically and persistently tracking incremental profiling data in a process cloning application environment 34, in accordance with the invention.  The system consists of a runtime environment 31 and individual classes 45 and class libraries 46 that form the overall core managed code platform.  By way of example, the system is described with reference to the Java operating environment, although other forms of managed code platforms that execute applications preferably written in an object oriented programming language, such as the Java programming language, could also be used.
The exemplary runtime environment 31 includes an application manager 32, master Java virtual machine (JVM) process 33 and zero or more cloned JVMprocesses 34.  The master JVM process 33 and cloned JVMprocesses 34 respectively correspond to a master runtime system process and child runtime system processes.  The master runtime system process, preferably provided as a virtual machine, interprets machine-portable code defining compatible applications.
The runtime environment 31 executes an application framework that spawns multiple independent and isolated user application process instances by preferably cloning the memory space of a master runtime system process.  The example of an application framework suitable for use in the present invention is the Unix operating system, such as described generally in M.J. Bach, supra at Ch. 2, the disclosure of which is incorporated by reference.
The application manager 32 presents a user interface through which individual applications can be selected and executed.  The application manager 32 and master JVM process 33 preferably communicate via an inter-process communication (IPC) mechanism, such as a pipe or a socket.  The master JVM process 33 is started at device boot time.
Upon initialization, the master JVM process 33 reads an executable process image from the storage device 43 and performs bootstrapping operations specified in a master warmup program 44.  The master warmup program 44 is an executable program performing a full range of operations and specifying warmup initialization actions, including preloading classes 45 and classes defined in the class libraries 46, precompilingmethods, and executing static initialization methods, such as respectively described in commonly-assigned U.S. Patent application Serial No. 10/745,023, entitled “System And Method For Dynamic Preloading Of Classes Through Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; Serial No. 10/745,020, entitled “System And Method For Providing Precompiled Code Through Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; and Serial No. 10/745,021, entitled “System And Method For Eliminating Static Initialization Overhead By Memory Space Cloning Of A Master Runtime System Process,” filed 22 December 2003, pending; the disclosures of which are incorporated by reference.  Thus, upon completion of initialization, the memory image of the master JVM process 33 resembles that of an initialized, primed and warmed up JVMprocess with key classes, methods and initialized state stored in the master JVM process context.
Following the initialization, the master JVM process 33 idles, that is, “sleeps” in an inactive state, while awaiting further instructions from the application manager 32.  The master JVMprocess 33 awakens in response to requests received from the application manager 32 to execute applications.  The application manager 32 sends a request to the master JVM process 33, including standard command line parameters, such as application name, class path, and application arguments.  The master JVMprocess 33 awakens and creates a cloned JVM process 34 as a new cloned process instance of the master JVMprocess 33 using the process cloning mechanism of the underlying operating system.  The context of the master JVM process 33 stored in memory as prewarmedstate 37 is inherited by the cloned JVM process 34 as inherited prewarmed state 41, thereby saving initialization and runtime execution times and providing deterministic execution behavior.  Following the “cloning” of the cloned JVM process 34, the master JVMprocess 33 records the launched application in an applications launched list 51 and returns to an inactive sleep state.
When implemented with copy-on-write semantics, the process cloning creates a logical copy of only the references to the master JVM process context.  Segments of the referenced master JVM process context are lazily copied only upon an attempt by the cloned JVM process to modify the referenced context.  Therefore, as long as the cloned JVM process does not write into a memory segment, the segment remains shared between parent and child processes.
The master JVMprocess 33 recognizes the following basic commands received from the application manager 32 through the IPC mechanism:
(1)  list:     Provides a list of applications launched in response to requests received from the application manager 32.
(2)  jexec:     Invokes the process cloning mechanism, parses command line arguments and executes a new instance of the master JVM process 33 as the cloned JVM process 34.  Preferably adopts a syntax compatible to standard JVMprocesses.
(3)  kill:     Terminates the application identified by an application handle or process identifier.
(4)  source:     Parses arguments and executes a program in the body of the master JVM process 33 without creating a cloned JVM process 34.  Subsequently cloned JVM processes 34 inherit the refined memory state of the master JVM process 33 resulting from the execution of a source command on behalf of the master JVM process 33.
Other commands are possible.
At device boot time, the master JVM process 33 executes the master warmupprogram 44 and the prewarmed state 37 and compiled method code in the code cache 38 are inherited by each cloned JVM process 34 as inherited prewarmedstate 41 and inherited compiled method code in the inherited code cache 42.  The master warmupprogram 44 is executed by the application manager 32 based on persistent profile data previously retrieved and stored from profile collectors 39 executing in one or more previously executed cloned JVMprocesses 34.  Also, each profile collector 39 collects and stores incremental profile data generated by a profiler 40 executing in one or more cloned JVMprocesses 34.  The dynamically profiled data is polled regularly by the application manager 32 to create a master dynamic profile 49, which is fed back into the master JVM process 33 using the source command to benefit subsequent cloned JVM processes 34.  The master dynamic profile 49 also forms the basis of a persistent profile that can be used by the master JVM process 33 upon the next device boot.
Each profiler 40 performs accounting on applications being executed, as would be appreciated by one skilled in the art.  The profiler 40 continually evaluates the application execution through, for example, an interpretive loop that attempts to identify important and performance sensitive code segments in the application.  By way of example, the profiler 40 identifies method invocations and system library calls through the accounting, which includes counting loop iterations and method invocations and by sampling running methods.  Other forms and approaches to performing accounting are possible.  Preferably, the profiler 40 applies a threshold to the data collected through profiling and identifies those methods exceeding the threshold.  The profile collector 39 evaluates the actions performed by the profiler 40 and stores those events affecting performance, such as class initializations and methods selected for dynamic compilation, as profile data.  Other types and forms of profile data are possible.
In one embodiment, the profile collector 35 of each cloned JVM process 34 stores the collected profile data transiently in a memory buffer 52.  Each cloned JVMprocess 34 maintains a profile request listener thread (not shown) executing concurrently to a main execution thread (also not shown).  The application manager 32 accesses the profile request listener thread using a suitable IPC mechanism, such as a socket.  At runtime, the cloned JVM process 34 listens to the profile thread through which the application manager 32 periodically sends profiling data queries, such polling requests.  In response, the cloned JVM process 34 sends incremental profile data to the application manager 32 and resets the memory buffer 52.  Only the profile data incrementally collected since the last profiling data query is staged in the memory buffer 52 and the application manager 32 stores assimilated sets of incremental profile data in the master dynamic profile 49.
In a further embodiment, the profile collector 35 of each cloned JVM process 34 stores the collected profile data persistently in a file as stored profiles 48.  At runtime, the application manager 32 iterates over the incremental profile data in the stored profiles 48, preferably on a periodic basis, for events of interest and stores evaluated incremental profile data in the master dynamic profile 49.  The incremental profile data can also be stored in both as transient profile data in the memory buffer 52 and as persistent profile data in the stored profiles 48.
At runtime, the application manager 32 maintains the master dynamic profile 49, which assimilates the incremental profile data received from each cloned JVM process 32.  The master dynamic profile 49 reflects dynamically observed events of interest, such as class initializations and methods selected for dynamic compilation.  This data can be used to fine tune the warmup initialization actions executed by the master JVM process 33 upon initialization to reflected actual usage patterns at runtime.  Thus, the application manager 32 analyzes the master dynamic profile 49 and updates the master warmup program 44.  In one embodiment, the application manager 32 persistently stores the master warmup list 44 as a file in the storage device 43 at device shutdown or on a periodic basis, such as in response to an automatic save feature.  Thereafter, at device boot time, the master JVM process 33 executes the saved master warmup program 44, which reflects the latest observed usage patterns.  The prewarmedstate 37 and compiled method code in the code cache 38 are then inherited by each cloned JVM process 34 as inherited prewarmed state 41 and inherited compiled method code in the inherited code cache 42.
In a further embodiment, the application manager 32 dynamically feeds the incremental profile data to the master JVM process 33.  The master JVM process 33 recognizes an additional basic source commands received from the application manager 32 through the IPC mechanism, such as described in commonly-assigned U.S. Patent application Serial No. 10/745,164, entitled “System And Method For Performing Incremental Initialization Of A Master Runtime System Process,” filed 22 December 2003, pending, the disclosure of which is incorporated by reference.  Briefly, executing a source command on the master JVM process 33 allows the warmup state, that is, the prewarmedstate 37 and code cache 38, to be incrementally initialized.  The application manager 32 sends the master warmup program 44 to the master JVM process 33 using the source command, which is executed to refine the context of the master JVMprocess 33.  Each subsequently spawned cloned JVM process 33 inherits the then-warmed up context as inherited prewarmed state 43 and code cache 38 executed by the master JVMprocess 33 up to that time.
Master JVM Process Mapping
FIGURE 3 is a block diagram 60 showing, by way of example, a master JVM process 33 mapped into memory 62.  Generally, the context for an executing process includes a data space, user stack, kernel stack, and a user area that lists open files, current directory and supervisory permission settings.  Other types of context can also be provided.  The context is stored and managed in the memory 62 by the operating system.  At device boot time, the operating system instantiates a representation of the executable master JVM process 33 into the memory 62, possibly in non-contiguous pages 64a-d, and records the allocation of the memory space as page table entries 63 into the page table 61 prior to commencing execution of the master JVM process 33.  As well, the master JVMprocess context could similarly be mapped using other memory management systems, such as using demand paging, swapping and similar process memory allocation schemes compatible with process cloning, particularly process cloning with copy-on-write semantics.
Cloned JVMProcess Mapping
FIGURE 4 is a block diagram 70 showing, by way of example, a master JVM process 33 and a cloned JVM process 34 mapped into memory 62 through memory space cloning.  In a system with process cloning that does not provide copy-on-write semantics, physical copies of the pages 64a-c in the memory 62 storing the parent process context are created for each child process.  In response to a process cloning request, the operating system instantiates a copy of the representation of the executable master JVM process 33 for the cloned JVM process 34 into the memory 62, possibly in non-contiguous pages 72a-d, and records the allocation of the memory space as page table entries 71 into the page table 61 prior to commencing execution of the cloned JVM process 34.  Thus, the cloned JVM process 34 is created with a physical copy of the context of the master JVM process 33.  Since a new, separate physical copy of the master JVM process context is created, the cloned JVM process 34 inherits the prewarmedstate 37, including the preloaded classes of the master JVMprocess 33.  However, the overall memory footprint of the runtime environment 31 is increased by the memory space required to store the additional copy of the master JVMprocess context.
Cloned JVMProcess Mapping with Copy-On-Write
FIGURES 5A-B are block diagrams 80, 90 showing, by way of example, a master JVM process 33 and a cloned JVM process 34 mapped into memory 62 through memory space cloning with copy-on-write semantics.  In a system with process cloning that provides copy-on-write semantics, only copies of the references, typically page table entries, to the memory space storing the parent process context are created for each child process.  Referring first to FIGURE 5A, in response to a process cloning request, the operating system copies only the page table entries 63 referencing the memory space of the executable master JVM process 33 as a new set of page table entries 81 for the cloned JVMprocess 34.  Thus, the cloned JVM process 34 uses the same references to the possibly non-contiguous pages 64a-d storing the master JVMprocess context as the master JVM process 34.  Initialization and execution of the application associated with the cloned JVM process 34 requires less time, as only the page table entries 62 are copied to clone the master JVM process context.  Furthermore, until the cloned JVM process 34 attempts to modify the master JVM process context, the memory space is treated as read only data, which can be shared by other processes.
Referring next to FIGURE 5B, the cloned JVM process 34 has attempted to modify one of the pages 82c in the memory space of the master JVM process context.  In response, the operating system creates a physical copy of the to-be-modified memory space page 82c as a new page 91 and updates the allocation in the page table entries 81 for the cloned JVM process 34.  Through copy-on-write semantics, the overall footprint of the runtime environment 31 is maintained as small as possible and only grows until, and if, each cloned JVMprocess 34 actually requires additional memory space for application-specific context.
Method for Dynamically Tracking Profiling Data Incrementally
FIGURE 6 is a flow diagram, showing a method 100 for dynamically and persistently tracking incremental profiling data in a process cloning application environment, in accordance with the invention.  The method 100 is described as a sequence of process operations or steps, which can be executed, for instance, by the runtime environment 31 of FIGURE 2 or other components. 
Initially, the application manager 32 is loaded (block 101).  The master JVM process 33 is loaded and initialized at device boot time (block 102), as further described below with reference to FIGURE 7.  Following loading and initialization, the master JVM process 33 enters an inactive sleep mode (block 103).  Upon receiving a request from the application manager 32 (block 104), the master JVM process 33 awakens (block 105).  If necessary, the master JVM process 33 checks the network connection identifier (ID) (block 106) for the application manager 32 and determines the type of request (block 107).  The master JVM process 33 recognizes the commands list, jexec, source, and kill, as described above with reference to FIGURE 2.  If the request type corresponds to a sourcecommand, instructing the master JVM process 33 to execute the master warmup program 44 (block 108), the master JVM 33 executes the master warmupprogram 44 (block 109), which refines or “enriches” the prewarmed state of the master JVMprocess 33, such that subsequently cloned JVMprocesses 34 spawned from the master JVM process 33 will inherit the refined context.  If the request type corresponds to a jexeccommand, instructing the master JVM process 33 to initiate an execution of an application through process cloning (block 110), a cloned JVM process 34 is cloned and executed (block 111), as further described below with reference to FIGURES 8 and 9.
Concurrently, the application manager 32 collects the profile data from the memory buffer 52 or stored profiles 48 (block 112).  Each profile collector 39 collects and stores incremental profile data generated by a profiler 40 executing in one or more cloned JVM processes 34.  The dynamically profiled data is polled regularly by the application manager 32 to create the master dynamic profile 49, which is fed back into the master JVM process 33 using the source command (block 108) to benefit subsequent cloned JVM processes 34.  Thus, if the master JVM process 33 is to be updated through feedback of incremental profile data (block 113), the application manager 32 warms up the master JVMprocess state by sending a source command (block 114).  The master dynamic profile 49 also forms the basis of a persistent profile that can be used by the master JVM process 33 upon the next device boot.  If maintained persistently (block 115), the master dynamic profile 49 is stored persistently, such as in a file (block 116).  Processing continues indefinitely until the application manager 32, master JVMprocess 33, and the runtime environment 31 are terminated.
Routine for Loading Master JVM Process
FIGURE 7 is a flow diagram showing the routine 120 for loading a master JVM process 33 for use in the method 100 of FIGURE 6.  One purpose of the routine is to invoke the master JVMprocess 33 and to warmup the master JVM process state for inheritance by cloned JVM processes 34.
Initially, the master JVMprocess 33 begins execution at device boot time (block 121).  The master JVMprocess 33 executes two sets of warmup actions using the master warmup program 44 and the master dynamic profile 49.  The master warmup program 44 is static and does not generally change between device boots, whereas the master dynamic profile 49 is subject to continual change based on the incremental profile data collected and assimilated by the application manager 32.  First, the master JVM process 33 executes the master warmup program 44 to form a memory image that resembles that of an initialized, primed and warmed up JVMprocess with key classes, methods and initialized state stored in the master JVM process context (block 122).  Second, if the application manager 32 maintains the master dynamic profile 49 persistently (block 123), the master JVM process 33 retrieves and executes the master dynamic profile 49 (block 124).  The master JVM process 33 then completes any other warmupoperations (block 125) and the routine returns.
Routine for Process Cloning without Copy-On-Write
FIGURE 8 is a flow diagram showing the routine 130 for cloning a process without copy-on-write for use in the method 100 of FIGURE 6.  One purpose of the routine is to create and initiate execution of a cloned JVMprocess 34 through process cloning that does not provide copy-on-write semantics.
Initially, the memory space containing the context of the master JVM process 33 is physically copied into a new memory space for the cloned JVMprocess 34 (block 131).  Optionally, the master JVM process 33 can set operating system level resource management parameters over the cloned JVMprocess 34 (block 132), including setting scheduling priorities and limiting processor and memory consumption.  Other types of resource management controls are possible. The cloned JVM process 34 is then executed by the runtime environment 31 (block 133) using the duplicated master JVMprocess context.  During execution, the cloned JVM process 34 profiles the application to create incremental profile data (block 134).  If the incremental profile data is stored persistently (block 135), the cloned JVMprocess 34 stores the incremental profile data as stored profiles 48 (block 136).  Otherwise, the incremental profile data is transiently staged in the memory buffer 52 (block 137).  The routine returns upon the completion (block 138) of the cloned JVM process 34.
Routine for Process Cloning with Copy-On-Write
FIGURE 9 is a flow diagram showing the routine 140 for cloning a process with copy-on-write for use in the method 100 of FIGURE 6.  One purpose of the routine is to create and initiate execution of a cloned JVMprocess 34 through process cloning that provides copy-on-write semantics.
Initially, references to the memory space containing the context of the master JVM process 33 are copied for the cloned JVM process 34 (block 141).  Optionally, the master JVM process 33 can set operating system level resource management parameters over the cloned JVM process 34 (block 142), including setting scheduling priorities and limiting processor and memory consumption.  Other types of resource management controls are possible. The cloned JVMprocess 34 is then executed by the runtime environment 31 (block 143) using the referenced master JVM process context.  During execution, the cloned JVM process 34 profiles the application to create incremental profile data (block 144).  If the incremental profile data is stored persistently (block 145), the cloned JVM process 34 stores the incremental profile data as stored profiles 48 (block 146).  Otherwise, the incremental profile data is transiently staged in the memory buffer 52 (block 147).  Each time the cloned JVM process 34 attempts to write into the memory space referenced to the master JVM process context (block 148), the operating system copies the applicable memory segment (block 149).  Otherwise, the cloned JVM process 34 continues to use the referenced master JVM process context (block 150), which is treated as read only data.  The routine returns upon the completion (block 151) of the cloned JVM process 34.
While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.
3. Brief Description of Drawings
FIGURE 1 is a functional block diagram showing, by way of example, runtime environments implemented on a plurality of heterogeneous devices.
FIGURE 2 is a block diagram showing a system for dynamically and persistently tracking incremental profiling data in a process cloning application environment, in accordance with the invention.
FIGURE 3 is a block diagram showing, by way of example, a master JVM process mapped into memory.
FIGURE 4 is a block diagram showing, by way of example, a master JVM process and a cloned JVM process mapped into memory through memory space cloning.
FIGURES 5A-B are block diagrams showing, by way of example, a master JVM process and a cloned JVM process mapped into memory through memory space cloning with copy-on-write semantics.
FIGURE 6 is a flow diagram showing a method for dynamically and persistently tracking incremental profiling data in a process cloning application environment, in accordance with the invention.
FIGURE 7 is a flow diagram showing the routine for loading a master JVM process for use in the method of FIGURE 6.
FIGURE 8 is a flow diagram showing the routine for cloning a process without copy-on-write semantics for use in the method of FIGURE 6.
FIGURE 9 is a flow diagram showing the routine for cloning a process with copy-on-write semantics for use in the method of FIGURE 6.
1. A system for dynamically and persistently tracking incremental profiling data in a process cloning application environment, comprising:
a runtime environment to clone a memory space of an executing master runtime system process as a child runtime system process responsive to a process request and executing the child runtime system process; and
a collector to profile the execution of the child runtime system process by collecting profiling data incrementally.
2. A system according to Claim 1, further comprising:
a memory buffer defined in a memory space of the child runtime system process to store the profiling data transiently.
3. A system according to Claim 2, wherein the runtime environment communicates the profiling data periodically from the memory buffer to an executing application manager process.
4. A system according to Claim 3, further comprising:
a profiling execution thread maintained with the application manager process in the child runtime system process; and
a response to provide the profiling data via the profiling execution thread responsive to a data request from the application manager process.
5. A system according to Claim 4, wherein the profiling execution thread comprises an inter-process communication mechanism.
6. A system according to Claim 3, wherein the profiling data is reset upon completing the communication to the application manager process.
7. A system according to Claim 1, further comprising:
a file to store the profiling data persistently at device shutdown or on a periodic basis.
8. A system according to Claim 7, wherein the runtime environment communicates the profiling data from the file to an executing application manager process.
9. A system according to Claim 1, further comprising:
an application model comprising a representation of at least one class from a source definition provided as object-oriented program code and associated with the application model, wherein the child runtime process selects one such application model specific class loader instance and the runtime environment communicates the application model selected by the child runtime system process to an executing application manager process.
10. A system according to Claim 1, further comprising:
a master warmup program defined as a source definition provided as object-oriented program code to consolidate the profiling data.
11. A system according to Claim 10, further comprising:
a file manager to store the master warmup program persistently in a file upon termination of the execution of an executing application manager process, wherein the runtime environment retrieves the master warmup program from the file, and interprets, instantiates and warms up the master warmup program into a memory space of an executing further master runtime system process.
12. A system according to Claim 11, wherein the runtime environment clones the memory space of the further master runtime system process as a further child runtime system process responsive to a process request and executing the further child runtime system process.
13. A system according to Claim 10, further comprising:
an application manager program to dynamically update the master warmupprogram during execution of the master runtime system process, wherein the runtime environment interprets, instantiates and warms up the master warmup program into the memory space of the master runtime system process.
14. A system according to Claim 1, wherein the profiling data comprises data selected from the group comprising class initializations, and methods selected for dynamic compilation.
15. A system according to Claim 1, further comprising:
a process cloning mechanism to instantiate the child runtime system process by copying the memory space of the master runtime system process into a separate memory space for the child runtime system process.
16. A system according to Claim 1, further comprising:
a copy-on-write process cloning mechanism to instantiate the child runtime system process by copying references to the memory space of the master runtime system process into a separate memory space for the child runtime system process, and to defer copying of the memory space of the master runtime system process until the child runtime system process needs to modify the referenced memory space of the master runtime system process.
17. A system according to Claim 1, wherein the master runtime system process is caused to sleep relative to receiving the process request.
18. A system according to Claim 1, further comprising:
a resource controller to set operating system level resource management parameters on the child runtime system process.
19. A system according to Claim 1, wherein the object-oriented program code is written in the Java programming language.
20. A system according to Claim 19, wherein the master runtime system process and the child runtime system process are Java virtual machines.
1. Abstract 
A system for dynamically and persistently tracking incremental profiling data in a process cloning application environment, comprising:
a runtime environment to clone a memory space of an executing master runtime system process as a child runtime system process responsive to a process request and executing the child runtime system process; and
a collector to profile the execution of the child runtime system process by collecting profiling data incrementally.
2. Representative Drawing 
none
2005216288.tif 000013
2005216288.tif 000014
2005216288.tif 000015
2005216288.tif 000016
2005216288.tif 000017
2005216288.tif 000018
2005216288.tif 000019
2005216288.tif 000020
2005216288.tif 000021
2005216288.tif 000022