(57)【要約】  複数のJavaアプリケーション・プログラムを同時にホスティングする（host）ことが可能な、変更されたJava仮想マシン（JVM）を動作するための方法及びシステムが開示される。当該JVMは、各々が一つ以上のクラスを有する一つ以上のアプリケーション・ドメインのコンピュータの記録を維持するために変更される。各アプリケーション・ドメインのために、アプリケーション・クラスの全ての割り当てられたインスタンスによって占有される複数のバイトにおける総メモリー量の第一利用カウントが維持される。好ましくは、このカウントは、アプリケーション・クラスの各新規インスタンスに伴って増加し、割り当てられた複数のアプリケーション・クラスを回収する各ガベージ・コレクション・イベントの間、又は当該イベントの後、減少する。【選択図】図７
2015519646.tif 000002
【特許請求の範囲】
【請求項１】
修正されたJVM又は前記修正されたJVMの単一の実行インスタンス内で複数のJavaアプリケーションをホスティングするためにJVMを修正する方法であって、前記JVMは、コンピュータのメモリ内に、一つ以上のアプリケーション・ドメインの記録を維持するよう変更され、各前記アプリケーション・ドメインは、一つ以上のアプリケーション・クラスを備え、各アプリケーション・ドメインのために、前記一つ以上のアプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの第一利用カウントが、前記コンピュータ・メモリ内で維持されることを特徴とする修正されたJVM又はJVMを修正する方法。
【請求項２】
請求項１に記載の修正されたJVM又はJVMを修正する方法であって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記第一利用カウントが、前記新たなインスタンスの占有メモリ・サイズと共に増加することを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項３】
請求項１又は２に記載の修正されたJVM又はJVMを修正する方法であって、前記第一利用カウントは、メモリのバイト数であることを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項４】
請求項１乃至３のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、前記占有メモリ・サイズは、前記新たなインスタンスによって占有されるバイト単位でのメモリ・サイズであることを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項５】
請求項１乃至４のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、前記割り当てられたインスタンスは、自身のメモリ・レイアウト内に、前記アプリケーション・クラスの前記アプリケーション・ドメインを特定する予約値（reserved value）を含むことを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項６】
請求項１乃至５のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記新たなインスタンスの前記予約値内に、前記アプリケーション・ドメインの前記特定の記録が作られることを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項７】
請求項１乃至５のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、前記アプリケーション・クラスは、自身のメモリ・レイアウト内に、自身が属する前記アプリケーション・ドメインを特定する予約値を含むことを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項８】
請求項１乃至７のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられていたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの第二利用カウントを記録することを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項９】
請求項１乃至８のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、ガベージ・コレクション・イベントの間に又はその後に、前記第一利用カウント値を、前記第二利用カウント値によりアップデートすることを特徴とする、修正されたJVM又はJVMを修正する方法。
【請求項１０】
請求項１乃至８のいずれか１項に記載の修正されたJVM又はJVMを修正する方法であって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの前記第一利用カウントをアップデートすることを特徴とする、修正されたJVM又はJVMを修正する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーション・プログラムをホスティングする（host）複数のサービスの動作に関連する。
【背景技術】
【０００２】
本発明に関連する先行技術は、以下に付随する図面を参照して述べられる。
【図面の簡単な説明】
【０００３】
【図１】単一のCPUを有する従来のコンピュータの動作を示す概略図である。
【図２】単一のCPU上の複数のアプリケーション・プログラムの動作を示す概略図である。
【図３】例えばJVMのようなアプリケーション・仮想マシンの概略図である。
【図４】単一のJVMと単一のアプリケーション・プログラムを動作する複数のCPUを有するサーバ・コンピュータの概略図である。
【図５】各々が単一のアプリケーション・プログラムを有する複数のJVMを動作させている複数のCPUを有するサーバ・コンピュータの概略図である。
【図６】複数のJVMと単一のオペレーティング・システムを動作させている複数のCPUを有するサーバ・コンピュータの概略図である。
【図７】単一のJVMと単一のオペレーティング・システムだが複数のアプリケーション・プログラムを動作させている複数のCPUを有する、ここで提案するサーバ・コンピュータの概略図である。
【発明を実施するための形態】
【０００４】
マルチテナント型の複数のアプリケーション・ドメインとメモリ管理を有する修正されたJVMである。
【０００５】
従来のコンピュータはコンピュータのユーザには明らかではないオペレーティング・システムによって管理される中央処理ユニット（CPU）を有する。アプリケーション・プログラムは、オペレーティング・システムとCPUとの双方を利用するコンピュータ上で実行される。この従来の構成は図１内で説明され、何年もの間実施されてきた。
【０００６】
複数のアプリケーション・プログラムを、単一の従来型のコンピュータ上で、各アプリケーション・プログラムを短い期間で連続的に動作させることによって実行することは周知である。これは、時分割多重手続（time divisional multiplex procedure）と等価であり、図２内で説明されている。
【０００７】
何年もの間、「アプリケーション仮想マシン」（application virtual machine）を動作させることも周知であり（http://en.wikipedia.org/wiki/Application_virtual_machine#Process_virtual_machinesをご参照のこと）、そこでは、アプリケーション・プログラム自身は、実行されるオペレーティング・システム、及び／又はCPUとの間で互換性がない言語（例えばJava）で書かれている。
【０００８】
しかし、Java仮想マシン（JVM）等のようなアプリケーション仮想マシンは、オペレーティング・システムとアプリケーション・プログラムとの間に位置する。従って、アプリケーション・プログラムのユーザに関する限り、たとえCPU及びオペレーティング・システムがJavaを用いてなくても、コンピュータはJava言語で動作する。この構成は、図３に示されている。
【０００９】
（例えばMySQLのような）データベース管理システム及び（Apache Httpdのような）ウェブ・サーバ・アプリケーションのような複数のサーバ・アプリケーションのホスティングのために特別に設計されたコンピュータがいくつか存在し、これらのコンピュータはサーバコンピュータと呼ばれるが、ホスティングされた（hosted）（単一の又は複数の）アプリケーション・プログラムを、単一のCPUを用いる場合よりも速く動作させるために、二つ以上のCPUを用いて設計される。様々な複数のCPUを用いた設計は、単一のサーバ・コンピュータ内の複数のCPUを動作させるための産業において周知である。最近のサーバ・コンピュータの設計は、一つのより大きなCPU装置（マイクロチップ）が、複数のビルト・イン型の、「CPUコア」と呼ばれるより小さなCPUを備える、「入れ子式（nested）」のCPU構成を包含する。どの複数のCPU構成が用いられるかに関わらず、各CPU又はCPUコアは、オペレーティング・システム・ソフトウェアにとって利用可能である。図４が示すのは、単一のJVMと単一のJavaアプリケーション・プログラムとを動作させる複数のCPUを有するそのようなサーバ・コンピュータの構成である。1990年代の終わりには、それより前の複数年の「サーバ当たり一つのアプリケーション・プログラム」モデルから生じる低サーバ利用率の現象に対処する手段として、サーバ仮想化が現れた。VMWによって今日提供されているESX及びCitirix XenServerといった製品のようなサーバ仮想化は、単一の物理的サーバ上で独立した複数のオペレーティング・システムを動作させることを可能にし、それによって、サーバ利用率を１５％の典型的なレベルからはるかに高いレベルに上昇させた。これは、図５に説明される。サーバ仮想化技術を用いる単一の物理的サーバ上の複数のアプリケーション・プログラムをマルチホスティングするアプローチは、「サーバ・コンソリデーション」と名付けられ、多くのアプリケーション及び負荷の場合のサーバ利用率の増加に成功することが証明された。（例えばMySQLのような）データベース管理システムや、（例えばApache Httpdのような）ウェブサーバ・アプリケーションのような複数のレガシー・アプリケーションのためのサーバ・コンソリデーションは、サーバ利用率の増加と、これらのアプリケーションのためのサーバインフラコストの減少において効果的であることが証明された。
【００１０】
しかし、この戦略に伴って最近認識されたのは、Java言語アプリケーションは、共有化されたサーバインフラ上に配置されると、他の言語（例えばC、C++）で書かれたアプリケーションと同じだけの効率の増加を享受しないということである。この理由は、Javaプラットフォームの当初の設計に由来し、当該プラットフォームは、単一の物理的サーバ環境上の複数のJavaアプリケーションの効率的なホスティングに対して制限や制約を課した。
【００１１】
共有化されたサーバインフラ上で効率的にJavaアプリケーションをホスティングするという課題は、アプリケーションのホスティングの選択肢としてのクラウド・コンピューティング環境の迅速な採用によって更に複雑になった。ここでは、独立の及び相互不信の（mutually-distrusting）顧客から、多くの独立したJavaアプリケーションが、共有化された物理的サーバインフラ上のクラウド・コンピューティング・ベンダによってホスティングされる（hosted）ことが求められる。これは、図６に説明されている。この関連において、「不信」という用語が意味するのは、他の未知の及び潜在的に悪意のあるアプリケーション・プログラムから隔離された安全な環境においてそれらのアプリケーション・プログラムを動作させたいという顧客の欲望のことである。元来、クラウド・ホスティング・ベンダが望むのは、購入されたサーバインフラへの投資の見返りを増加させるために、出来るだけ１００％に近いサーバ利用を達成することである。これらのクラウド・コンピューティング環境において、未使用のCPUサイクルであれ、未使用のメモリのバイト数であれ、未使用のサーバの能力は、ホスティング・プロバイダにとっての金銭的損失を表すが、これは、これらの動いていないリソースにおいては、ホスティング・プロバイダは収入が得られないからである。
【００１２】
共有化されたサーバ環境内、及び、より最近においては、クラウド・コンピューティング環境でのJava言語アプリケーション・プログラムの非効率性は、自身のホスティングされた負荷のための１００％に近いサーバ利用を達成することを求めるホスティング・プロバイダにとっての重要な課題領域として特定される。Javaの非効率性の理由は、Javaプラットフォームの設計と性質及び、現代のJava仮想マシンが今日いかにして動作するかの原理に由来する。例えば、Javaプラットフォームは、その設計の中に、アプリケーション・プログラムの動作のためにもはや必要とされていない、メモリー・レコード、クラス、フィールド、オブジェクト等の削除による、Javaアプリケーション・プログラムのメモリ管理の自動化のための、「ガベージ（garbage）」コレクションの技術の使用を含む。しかし、ガベージ・コレクションは、Javaアプリケーションをホスティングする（host）Java仮想マシン上に大きな負荷を与える。というのも、非効率的なガベージ・コレクション・アルゴリズムは、ガベージ・コレクション手続きが動作される際に、アプリケーションの実行の頻繁な中断と長い休止時間によりJavaアプリケーションのパフォーマンスと利便性を大きく損ない得るからである。
【００１３】
Javaアプリケーションのためのガベージ・コレクションのオーバーヘッドを削減する試みにおいて、現在のJVMは、休止時間とJavaアプリケーションの実行の中断を減らす、並列的及び並行的コレクション・アルゴリズムに基づく高度なガベージ・コレクション技術を取り入れている。しかし、これらの現代の並列的及び並行的なガベージ・コレクション・アルゴリズムは、下層の物理的サーバのCPUとメモリ・リソースの大きな消費によってこの改善を実現する。
【００１４】
例えば、「ガベージ・ファースト（garbage first）」アルゴリズムのような、現代の並列的なガベージ・コレクション・アルゴリズムにおいて、JVMは、下層のオペレーティング・システムにとって利用可能な各物理的CPUコアに対して、少なくとも一つのガベージ・コレクター・スレッドを割り当て、各コレクター・スレッドを指定のCPU（又はCPUコア）に固定し（又はロックし）、それから、これらのスレッドを、アプリケーションの実行と並行的に動作させる。結果として、Javaアプリケーション自身が遊んでいる際ですら、「ガベージ・ファースト」コレクター・アルゴリズムを使用するJVMは、下層のオペレーティング・システムにとって利用可能なCPUコアの全てを占めるに十分なスレッドを割り当て、利用可能なCPUコアの全てにおけるバックグラウンドにおいて、これらのコレクター・スレッドを並行的に実行するであろう。
【００１５】
ただ一つのJVMが、オペレーティング・システムによって一度動作される限りにおいて、JVMとJavaアプリケーションは、常に、自身のピークの可能なパフォーマンスにおいて、機能することが可能である。しかし、（例えば、業務時間外に経るであろう）低計算負荷の期間を経るエンタープライズ・アプリケーションの場合にはよくあることだが、クラウド・コンピューティングのベンダやJavaアプリケーションをホスティングしようとする他のベンダは、共有化された物理的サーバインフラ上で複数のJavaアプリケーションをロード可能であることを望む。共有化されたサーバインフラ及びクラウド・コンピューティングの環境上の複数のJavaアプリケーションのホスティングの非効率性は、従って、複数の独立したJVM内で実行される複数の独立したJavaアプリケーションが、単一の共有化された物理的サーバ及びオペレーティング・システム上でホスティングされる（hosted）ことが試みられる際に生じる。
【００１６】
例えば、共有化されたオペレーティング・システム上で第一のJVMを開始した後、そのJVMは、典型的には一つのガベージ・コレクター・スレッドを、当該オペレーティング・システムにとって利用可能な各CPUコアに割り当て、同時ガベージ・コレクション・アルゴリズムを用い、アプリケーションの実行と並行的に、各CPUコア上でこれらのスレッドを動作するであろう。それから第二のJVMが、同一の物理的サーバ上で開始されることが試みられ、システム環境を動作する際に、複数の問題が発生する。第二のJVMが開始すると、それは、第一のJVMと同様に、一つのガベージ・コレクター・スレッドを、下層のオペレーティング・システムにとって利用可能な各CPUコアに割り当てるであろう。しかし、第一のJVMは既に同じことをまさに既に実行している。従って、二つのJVMの各々が、利用可能なCPUコアを消費するに十分な複数のスレッドを割り当てた状況が発生する。すなわち、各コアは、各JVMから自身に割り当てられた一つのガベージ・コレクター・スレッドを有するが、各JVMは、（実際にはそうではないのだが）そのCPUコアの使用に対する制御を握っていること考えられている。二つを超えてより多くのJVMが同時に開始される場合に明らかなように、この問題は、比例的に悪化する。従って、二つ以上のJVMが、ガベージ・コレクションの活動の実行を同時に開始する時に、問題のある挙動が観察され始めるであろうが、それは、各CPUコア上でバックグラウンド・ガベージ・コレクションの複数の義務を実行するために、各JVMが他の単一のJVM（又は他の複数のJVM）と競合するためである。これによって各CPUコア上での際立った競合点が生じるが、それは、各JVMの複数のスレッドが、各々のガベージ・コレクションとそれ以外のJavaプラットフォーム管理義務を実行するために、他の各JVMの複数のスレッドと競合することによるものであり、その結果、CPU及びメモリの実質的な負荷が生じ、それと共に、ホスティングされる複数のJavaアプリケーションのパフォーマンスが極めて明白に遅くなる。
【００１７】
（本発明の発端）
従って、このような状況によって、共有化されたサーバインフラ及びクラウド・コンピューティングの環境における複数のJavaアプリケーションのホスティングが顕著に非効率的であるという認識に導かれる。本発明の発端は、共有化されたサーバインフラ及びクラウド・コンピューティング環境上での複数のJavaアプリケーションをホスティングするための、より効率的な機構を発想したいという要求である。
【００１８】
（先行技術の詳細な分析）
これらの複数のアプリケーションを単一の共有化されたJVM内でホスティングすることによって、共有化されたサーバインフラ上で複数のJavaアプリケーションをより効率的にホスティングするために、、多くの方法が提案されてきた。このような望ましい構成の説明は図７に示されている。仮にこれが可能であれば、共有化されたサーバインフラ又はクラウド・コンピューティング環境上での複数のJavaアプリケーションをホスティングする非効率性は、少なくとも部分的に解決される。これは、単一のJVMが、所与の物理的サーバ、及び／又は、オペレーティング・システムのために開始されることが可能であり、それにより、複数のJavaアプリケーションがその単一のJVM内でホスティングされる（hosted）ことが可能だからである。このようにして、単一のJVMは、同一の共有化されたオペレーティング・システム又は物理的サーバ上で動作する他の複数のJVMインスタンスとの競合（contention）又はコンペティション（competition）とは関係なく、直近の並列的及び並行的ガベージ・コレクション・アルゴリズムを用いることが可能であるが、それは、そのオペレーティング・システム／サーバ装置上のただ一つのJVMだけが、他の競合する複数のJVMから干渉されることなく、そのガベージ・コレクション・アルゴリズムを実行可能だからである。
【００１９】
しかし残念なことに、Java仮想マシン仕様、Java言語仕様、及びJavaアプリケーション・プログラミング・インターフェース（API）仕様を備えるJavaプラットフォームは、決して、単一の共有化されたJVM内における、複数の独立したスタンドアローンのアプリケーションのホスティングを予期していなかった。Javaプラットフォーム仕様が設計された際、設計者は、JVMモデル当たり一つのアプリケーション（one-application-per-JVM）を予測しており、関連する仕様はそれに従って定義された。
【００２０】
例えば、Javaプラットフォーム仕様によって定義されるJavaAPIの複数のクラスの内の一つは、java.lang.Systemクラスである。当該java.lang.Systemクラスは、三つの公的にアクセス可能なフィールド変数、すなわち、in、out、及びerrを含み、それらは各々、setIn()、setOut()、setErr()によってそれぞれ設定されても良い。Javaプラットフォームの仕様は、単一のjava.lang.Systemクラスのみが、JVMごとにロードされ定義されても良く、従って、これらの三つのフィールド変数の単一の出現のみがJVMごとに存在しても良いことを明記している。これによって、二つのアプリケーションが同一のJVM内で直ちに動作されることが試みられる際、重大な問題が生じるが、それは、各アプリケーションが、setIn()、setOut()、及びsetErr()ファンクションによって、自身の使用のために、フィールド変数内にSystem.out/err/inのセットアップを制御することを想定するからである。Javaプラットフォームの仕様は、これらの複数のフィールド変数を、各々が一つのユニークな値を有するもののみに制限するので、単一のJVM内で並行的に動作することを試みる二つの（またはそれより多い）Javaアプリケーションの内一つのみが、全てのアプリケーションに対してこれらの単体のフィールド変数を制御することが可能となるであろう。他のアプリケーションは、それらを設定する、最後に制御するアプリケーションのin/out/errフィールドの使用を強制されるであろう。
【００２１】
java.lang.Systemクラスは、安全かつ確実に単一の共有化されたJVM内で複数の独立したアプリケーション・プログラムをコ・ホスティングする（co-host）試みを失敗させるJavaプラットフォームの仕様に内在する、多くの制限及び限定の一つの例にすぎない。Javaプラットフォームのためのマルチテナント型フレームワークを案出する試みを失敗させるJavaプラットフォーム仕様の他の重要な例は、コ・ホスティングされる複数のアプリケーション間にあるJVMヒープ・メモリのメモリ・アカウンティング及びメモリ・パーティショニングの試みの周囲にある。
【００２２】
VMware ESX及びCitrix XenServerのようなJavaではないアプリケーション・プログラムのための現存するサーバ仮想化製品は、単一の共有化された物理的サーバ上で動作する複数の仮想マシン間の大規模な（extensive）メモリ・アカウンティング及びメモリ・パーティショニングの特徴を提供する。これらのメモリ・アカウンティング及び制御の特徴は、安全かつ確実に、コ・ホスティングされるアプリケーション間で利用可能なシステム・メモリを分割し、一つのアプリケーション・プログラムが、他の隣接するアプリケーション・プログラムのメモリを消費せず、当該メモリと干渉できないことを確実にする複数のポリシを実行するために用いられる。
【００２３】
しかし、Javaプラットフォームの仕様においては、複数のアプリケーション・クラス間のイントラ・ヒープ・メモリ・アカウンティング又はメモリ・パーティショニングの手段は提供されていない。結果として、単一の先行技術のJVM内でロードされる任意のアプリケーション・クラスが、意図的であるか否かにかかわらず、減速（moderation）なく、他のアプリケーション・クラスと共有されるJVMヒープ・メモリを消費することが可能であり、潜在的な結果として、（一つ以上の他のアプリケーション・クラスが同一のアプリケーションの一部であるか否かにかかわらず）当該一つ以上の他のアプリケーション・クラスにとってのメモリ不足が生じる。
【００２４】
Javaプラットフォームの仕様を通じて、コ・ホスティングされる複数のアプリケーションの一つ又は全てにとっての誤った動作や安全性に対する侵害のリスクを冒すことなく、完全に独立に及び同時に、複数のアプリケーションをホスティングすることを、Javaプラットフォームの仕様に従った現存するJVMにとって、実現困難とする制限や限定が存在する。それにも拘らず、単一の共有化されたJVM内のコ・ホスティングされる複数のアプリケーションをサポートするために様々な戦略がこれまで提案されてきたが、これらの先行する手段は、単一の共有化されたJVM内の複数のJavaアプリケーションをコ・ホスティングする際に直面する、メモリ・アカウンティング及びメモリ・パーティショニングの試みに対処していない。
【００２５】
単一のJVM内で複数のアプリケーションをホスティングするそのような先行技術の試みの一つには、マルチホスティングの構成における使用のために許可されるJavaプラットフォームの仕様の制限されたサブセットの定義、及び、（例えば、同時にホスティングされる複数の独立したアプリケーション・プログラムが存在する際に安全で確実ではない）マルチテナント型の動作にとって安全でも確実でもないJavaプラットフォームの仕様の許可されていない他の動作と特徴の全てを許可しないことが伴う。この先行技術による方法の一つの例が、JavaのためのグーグルのAppEngineであって、そこでは、「JREホワイト・リスト」が定義され、プログラマとアプリケーションの開発者に、Javaプラットフォームの仕様のどの部分が、グーグルのAppEngineシステム上で使用することが許可されているか、及び、どの部分の使用が許可されていないかを知らせている（https://developers.google.com/appengine/docs/Java/jrewhitelistをご参照のこと）。JREが表わしているのは、Java Runtime Environmentである。アプリケーション・プログラマが自身をこの狭められた特徴のリストに制限する限りにおいて、グーグルのAppEngineは、グーグルによって動作されるマルチテナント型のJVM環境における自身のアプリケーションを展開することが可能である。グーグルのAppEngineが、複数のファイル、ソケット、スレッドなどを、ホスティングされるアプリケーションが使用することを制御するために、様々なメカニズムを提供する一方で、コ・ホスティングされる複数のアプリケーションの間の共有化されたJVMヒープ・メモリの使用を制御するためのメモリ・アカウンティング又はメモリ・コントロールの特徴は提供されない。結果として、グーグルのAppEngineシステム上で動作する、一つの悪意のある（又は権限のない）アプリケーション・プログラムが、潜在的に、利用可能な共有化されたJVMヒープ・メモリの全てを消費し得るため、結果として、同一の共有化されたJVM内の、コ・ホスティングされる他のアプリケーション・プログラムは、自身の動作のためにアクセスする十分なJVMヒープ・メモリに欠乏する。
【００２６】
Javaプラットフォームのためのマルチテナント型のフレームワークにおける他の試みは、米国特許６，９３１，５４４号（Kienhoefer/The SCO Group, Inc）の明細書で定義されており、そこでは、Javaのプラットフォームの仕様によって定義されるjava.lang.SecurityManagerのような安全性管理設備の大規模な使用が、異なる（differing）複数の許可と複数の特権を、単一のJVM内で動作するコ・ホスティングされる（co-hosted）複数のアプリケーションに適用するために用いられる。米国特許６，９３１，５４４のコ・ホスティング（co-hosting）技術の記載は、サン・マイクロシステム（現在のオラクル）や他社によって提供されるJVMのような修正されていない（unmodified）JVMを用いた使用を明確に志向している（特許明細書のcolumn 3, line 56-59、及び、column 4, line 4-9をご参照のこと）。米国特許６，９３１，５４４号が避けているのは、現存する修正されていないJVM及び修正されていないJavaAPIクラスの上層でのコ・ホスティング・サポート（co-hosting support）を組み込む試みにとって有利になるように、下層のJVM又はJavaプラットフォームの仕様を変更することである。コ・ホスティングされるアプリケーションによる複数のファイル、ソケット、及びスレッドの使用を適度にするために、いくつかの単純な制御メカニズムが述べられている一方で、並行的に実行されるアプリケーション・プログラムの安全で確実な動作を確実にするための、コ・ホスティングされるアプリケーションによる、共有化されたJVMヒープ・メモリの使用を適度にするためのアカウンティング又は制御方法は開示されていない。
【００２７】
C及びC++といったプログラミング言語のようなプログラミング言語とは異なり、Javaのプログラミング言語は、JVM内の自動メモリ管理システムを提供し、当該システムは、アプリケーション・プログラムのためにメモリの割り当て及び回収（reclamation）の全ての面を制御する。JVMは、「Javaヒープ・メモリ」のスペースを定義し、そこでは、JVMに組み込まれたガベージ・コレクション・サービスを用いて、全てのJavaオブジェクトが、JVMによってロードされ、監視される（tracked）。結果として、Javaのプログラミング言語で書かれたアプリケーション・プログラムは、メモリ回収の負荷（duty）を、自身のためにJVMによって実行させるが、C及びC++言語で書かれたアプリケーション・プログラムのような手動のメモリ管理の必要はない。
【００２８】
Javaプラットフォームのためのマルチテナント型のフレームワークの設計時には、アプリケーションの互換性及び基本的な機能的制御の課題（challenge）に対処するだけではなく、共有化されたJVMヒープ・メモリが、その単一の共有化されたJVM上で動作する、並行的にホスティングされる複数のアプリケーション・プログラムの各々によって、どのように割り当てられ消費されるかということに対する制御を提供する必要がある。しかし残念なことに、上記の二つの先行技術による方法の何れも、安全で確実な方法で、単一の共有化されたJVM内の複数の独立したアプリケーション・プログラムをホスティングする、メモリ・アカウンティング及びメモリ・パーティショニングの課題の何にも対処していない。本発明が開示するのは、これらの以前の方法の制限と安全上の脆弱性を十分に克服する構成である。
【００２９】
「複数のJava APIクラス」及び「単一のJavaAPIクラス」なる用語の使用は、Javaプラットフォームの仕様によって定義される（java.lang.Objectのような）複数のクラス、又は、例えば、java.lang.Thread、java.io.File、及びjava.io.FileSystemのようなjava.*.packageネームスペースの一部分として定義される複数のクラスのいずれかを意味するものと理解される。
【００３０】
「クラス定義」なる用語の使用は、例えば、java.lang.ClassLoader.defineClass (String name, byte[] buffer, int offset, int length)及び関連する技術によって生成されてもよい、ユニークなjava.lang.Classインスタンス、又は、ブートストラップ・クラス・ローダによって表されるクラスの種類を意味すると理解される。二つ以上のクラス定義は、同様に名づけられたクラス（例えば、org.example.ClassA）のためにロードされてもよく、その結果、その一つ一つが各クラス定義のためである、複数のユニークなjava.lang.Classインスタンスとなる。同一の名前を共有する二つのクラス定義（例えば、java.lang.Class.getName()メソッドによって報告される）は、例えば、Javaのオペレーションである、“org.example.ClassA.class != org.example.ClassA.class”、又は“new org.example.ClassA().getClass() != new org.example.ClassA().getClass()”、又は “instanceOneOfClassA.equals( instanceTwoOfClassA ) == false”によって決定されるように、その各々のjava.lang.Class参照が等しくないのであれば、ユニークであって、同一のクラス定義ではない。同一の名前による異なるクラス定義は、同一であったり、同一のバイトコードを用いて定義されたり、同一数及び構成の複数のメソッド、フィールド、及びコンストラクターを有することは要求されない。
【００３１】
「ブートストラップ・クラス・ローダ」なる用語の使用は、Javaプラットフォームの仕様内で述べられるブートストラップ・クラス・ローダ、又は、そのクラス・ローダによって定義されるいくつかの又は全てのクラスが、“null”を、前記複数のクラスのjava.lang.Class.getClassLoader()メソッドに返す、他の任意のクラス・ローダを意味するものと理解される。
【００３２】
「アプリケーション・クラス・ローダ」なる用語の使用は、Javaプラットフォームの仕様内で述べられるユーザによって定義されたクラス・ローダ、又は、そのクラス・ローダによって定義されるいくつかの又は全てのクラスが、“null”を、前記複数のクラスのjava.lang.Class.getClassLoader()メソッドに返さない任意のクラス・ローダを意味するものと理解される。
【００３３】
ここでの「JVM」なる用語の使用は、Java仮想マシンの仕様及び関連するJavaAPIクラスのセットの実装を備えるJava仮想マシンを意味するものと理解される。いくつかのJVMにおいては、JavaAPIクラスは、別個に開発され又は維持され、動作時（ランタイム）にJVMとのみリンクする。この仕様の目的のために理解されるべきは、「JVM」なる用語が、そのようなランタイムにリンクされるJavaAPIクラスを含むということであるが、これらのJavaAPIクラスのいくつか又は全てが、JVMの残りと分割して維持されるか否かには関係ない。
【００３４】
現存するJVMの例は、OpenJDK JVM、Oracle HotSpot JVM、Oracle JRocket JVM、IBM J9 JVM、JikesRVM、Maxine JVM、及びWaratek DRLVMを含む。
【００３５】
（開示の要約）
単一で実行するJVMインスタンス内の複数の独立したJavaアプリケーションを、安全で確実な方法で同時に動作することが可能な、修正されたJVMについて述べられる。本明細書内で教示される当該修正されたJVMの構成は、先行技術によるJVMのメモリの割り当て及び回収（reclamation）の機能を改善するが、それには、単一の共有化されたJVM内で共にコ・ホスティングされる（co-hosted）複数の独立したアプリケーション・プログラムのメモリ消費を測定する能力が伴う。これは、以下に記載するJVMに対する多くの変更によって実現される。
【００３６】
第一の変更によって、JVMは、その単一のJVM内の並行的にホスティングされる各アプリケーション・プログラムのレコードを維持するよう修正される。当該JVM内でホスティングされる各アプリケーションのために、そのアプリケーション・プログラムを備える一つ以上のアプリケーション・クラスのためにコンピュータのメモリ内にアプリケーション・プログラム・レコードが維持され、複数のアプリケーション・クラスの動作の統計値のセットが、そのアプリケーション・プログラム・レコード内に維持される。
【００３７】
修正されたメモリ・アカウンティング手続きが、一つのアプリケーション・プログラムの消費メモリ容量を正確に数える（account for）ことを可能とするために、そのアプリケーション・プログラム・レコードと複数の統計値を維持することが必要である。このアプリケーション・プログラム・レコードは、例えば、リスト、表、又は構造体（struct）のようないくつかの形態をとっても良い。表１Ａが示すのは、いくつかのカウント値が示されるそのような構造体の形態である。
【００３８】
各アプリケーション・プログラム・レコードに対して、一つのアプリケーション・プログラムの複数のアプリケーション・クラスによって割り当てられる複数のオブジェクトによって占有されるメモリ容量の、少なくとも一つの統計的なカウント値が提供されることが必要である。そのようなカウント値は、例えば、そのアプリケーション・プログラム・レコードに関連する複数のアプリケーション・クラスによって割り当てられる、複数のオブジェクトによって消費される総メモリのバイト数等の、幾つかの形態をとっても良い。またいくつかのユニークなカウント値を、例えば表１Ａが示すような所与のアプリケーション・プログラム・レコードのために維持することも可能である。例えば、所与の期間に亘って複数のアプリケーション・クラスによって割り当てられる全てのオブジェクトのバイト単位の総サイズのために、一つの統計的なカウント値を維持し、その一方で、所与のアプリケーション・プログラム・レコードに属する複数のアプリケーション・クラスによって割り当てられ、且つ、その所与の期間に亘って回収され（reclaimed）（又は削除され）る全てのオブジェクトのバイト単位の総サイズのために、第二の統計的カウント値を維持することが望ましい。このような複数のカウント値の構成が用いられるとき、例えば、第一のカウント値から第二のカウント値を減算することにより複数の関連カウント値を比較する計算によって、所与のアプリケーション・プログラムにより消費されるJVMヒープ・メモリの正確な示度を決定することが可能である。複数のカウント値の他の構成が可能である。
【００３９】
また、第二の変更が、アプリケーション・クラスが属するアプリケーション・プログラム・レコードをルックアップするためのルックアップ手続き又はルックアップ関数を提供するためになされる。これは、種々の可能な構成のうちの何れかにより実現可能である。第一の構成においては、各アプリケーション・クラスの内部クラスの代表（representation）（例えば、そのアプリケーション・クラスを表すユニークなjava.lang.Classインスタンス）が、そのアプリケーション・クラスが属するアプリケーション・プログラム・レコードを特定するフィールド又は変数（variable value）を含むように修正される。第二の構成においては、ハッシュテーブル（hashtable）又はこれと同様なデータ構造のようなマスタ・リストが、複数のアプリケーション・クラス（例えば、各アプリケーション・クラスのユニークなjava.lang.Classの参照）を、それらが属するアプリケーション・クラス・レコードに関連付けるために提供される。
【００４０】
第三の変更によって、JVMの（単一の又は複数の）メモリ割り当て機能が、アプリケーション・クラスによって割り当てられることが試みられている新たなオブジェクトの大きさを用いて、アプリケーション・プログラム・レコードの（単一の又は複数の）カウント値をアップデートするために変更される。JVMの複数のメモリ割り当て機能は、様々な形態をとることが可能である。メモリ割り当て機能は、様々なオペレーティング・システムのmalloc()ファンクションに類似する手続き呼び出しの形態をとることが可能であり、そこでは、メモリ割り当て機能の呼び出し元は、そのクラスのメソッド・バイトコード内のNEWインストラクションによって新たなオブジェクトを構成することを試みるアプリケーション・クラスである。表１Ｂが示すのは、javapツールによって生成された逆アセンブル後の命令シーケンスのフォーム内における、アプリケーション・クラスのメソッド・バイトコードの抜粋であり、そこでは、NEWインストラクション２３が、そのアプリケーション・クラスのメモリ割り当て命令を表している。特定のJVMに依存して、NEWインストラクションは、様々な方法で実装されても良い。一つの形態においては、NEWインストラクションを、ジャスト・イン・タイムのコンパイラによって、新たに割り当てられるオブジェクトを備えることとなるメモリを割り当てるJVM関数への関数呼び出しに変換することが可能である。他の形態においては、NEWインストラクションは、ハードウェア・プロセッサによって、又は、ソフトウェアに実装される命令インタープリタによって、新たに割り当てられるオブジェクトを備えることとなるメモリを割り当てるものと解釈されても良い。典型的には、割り当てられる新たなオブジェクトの大きさは、NEWインストラクションへパラメータとして渡されるクラス参照又はクラス表現に格納されている情報から決定することが可能である。他の形態のメモリ割り当て機能は、コンピュータ技術における当業者にとって周知であろう。
【００４１】
一つの構成においては、複数のJVMのメモリ割り当て手続きは、例えばジャスト・イン・タイムのコンパイラによって、メモリ割り当て手続きを呼び出すアプリケーション・クラスのアプリケーション・プログラム・レコードを特定する呼び出しにおいてパラメータを渡し、そのように特定されたアプリケーション・プログラム・レコードのカウント値を、割り当てられる新たなオブジェクトの大きさでアップデートするために変更される。そのようなパラメータは、アプリケーション・プログラム・レコードを特定するユニークな整数値、又は、コンピュータ・メモリ内のアプリケーション・プログラム・レコードのポインタ又はメモリ・アドレス値の形態をとることが可能である。
【００４２】
他の構成においては、複数のメモリ割り当て手続きは、そのような目的のために提供されるルックアップ手続きを利用する割り当て手続きを呼び出し、メモリ割り当て機能を呼び出すアプリケーション・クラスに関連するアプリケーション・プログラム・レコードのカウント値を、割り当てられる新たなオブジェクトの大きさでアップデートするアプリケーション・クラスを特定するために変更される。
【００４３】
更に他の構成においては、複数のメモリ割り当て手続きは、アプリケーション・クラスのアプリケーション・プログラム・レコードを特定するスレッド・ローカル・ストレージ値を読むために変更され、そのように特定されたアプリケーション・プログラム・レコードのカウント値を、新たに割り当てられるオブジェクトの大きさでアップデートする。
【００４４】
用いられる厳密な構成に関わらず、JVMの複数のメモリ割り当て機能は、一つのアプリケーション・クラスによってそれらの機能が呼び出されたならば、メモリ割り当て機能が、（ｉ）メモリ割り当て機能を呼び出したアプリケーション・クラスのアプリケーション・プログラム・レコードを特定し、（ｉｉ）その目的のためにアプリケーション・プログラム・レコード内に維持されているカウント値に対して、新たに割り当てられるオブジェクトのメモリサイズをバイト単位で加えることが可能である、という効果を実現するために変更される。
【００４５】
メモリの回収（又は削除）機能を変更しないと、関連する複数のアプリケーション・クラスのメモリ消費量を示しているアプリケーション・プログラム・レコードのカウント値は、JVMの複数のガベージ・コレクション機能によって回収されたメモリを反映するように減ることは決してなく、継続的に増加するようであった。従って、四つ目の変更によって、JVMの複数のメモリ回収機能は、クラスによって以前割り当てられ、現在はガベージ・コレクション機能によって現在回収中（又は削除中）の複数のオブジェクトの回収（又は削除）を反映するために、アプリケーション・プログラム・レコードの複数のカウント値をアップデートするために、修正される。
【００４６】
従って、（一つ又は複数の）JVMのガベージ・コレクション機能は、二つの点のうちの一つの点において修正される。一つ目の構成においては、複数のガベージ・コレクション機能が修正され、その結果、ガベージ・コレクション・サイクルの各マーキング・フェイズ(marking phase)において、そのガベージ・コレクション・サイクルの間に遭遇した（encountered）（マーキングされた）複数の生存オブジェクトの数、及び／又は、大きさの、各アプリケーション・プログラム・レコードのために、統計的なカウント値が維持され、及び／又は、アップデートされる。
【００４７】
第二の構成においては、複数のガベージ・コレクション機能が修正され、その結果、ガベージ・コレクション・サイクルの各マーキング・フェイズにおいて、そのガベージ・コレクション・サイクルの間に回収される複数のオブジェクトの数、及び／又は、大きさの各アプリケーション・ドメインのために、統計的なカウント値が維持され、及び／又は、アップデートされる。
【００４８】
ここでの「アプリケーション・ドメイン」なる用語の使用は、複数のアプリケーションを同時に動作させることが可能な単一のJVM内で動作する、一つ以上のアプリケーション・クラスを備える単一のアプリケーション・プログラムを意味するものと理解される。
【００４９】
ここでの「複数のアプリケーション・クラス」なる用語の使用は、単一のアプリケーション・プログラムの一部又は全てを備える、単一のJVM内の一つ以上のJavaクラス・ファイル及びそれらの内部表現を意味するものと理解される。
【００５０】
「ガベージ・コレクション・サイクル」又は「ガベージ・コレクション・イベント」なる用語の使用は、複数の生存オブジェクトによってもはや使用も参照もされず、回収されてもよいコンピュータ・メモリ内の複数のJavaオブジェクトを特定することに向けられている、単一のJVMの複数のガベージ・コレクション・ルーティン又は手続きの周期的な実行を意味するものと理解される。
【００５１】
「マーク・フェイズ(mark phase)」なる用語の使用は、どのオブジェクトが生存参照によって到達可能であり、従って回収不可能であり、どのオブジェクトが生存参照によって到達不可能であり、従ってやがて回収可能となるかを決定することに向けられている、複数のガベージ・コレクション・ルーティン又は手続きを意味するものと理解される。
【００５２】
本発明の第一の観点に従えば、当該修正されたJVMの単一の実行インスタンス内で、複数のアプリケーション・プログラムをホスティングするための修正されたJVMが開示され、前記JVMは、コンピュータ・メモリ内に、各前記アプリケーション・プログラムのための単一のアプリケーション・プログラム・レコードを維持するために修正され、各前記アプリケーション・プログラムは、一つ以上のアプリケーション・クラスを備え、各アプリケーション・プログラム・レコードのために、前記一つ以上のアプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの第一利用カウントが、前記コンピュータ・メモリ内に維持される。
【００５３】
好ましくは、前記複数のアプリケーション・クラスの新たなインスタンスの各割り当てのために、前記第一利用カウントは、前記新たなインスタンスの占有メモリ・サイズと共に、増加される。
【００５４】
好ましくは、前記第一利用カウントは、メモリのバイト数である。
【００５５】
好ましくは、前記占められるメモリ・サイズは、前記新たなインスタンスによって占有されるバイト単位のメモリ・サイズである。
【００５６】
好ましくは、前記割り当てられた複数のインスタンスは、自身のメモリ・レイアウト内に、前記複数のアプリケーション・クラスの前記アプリケーション・プログラム・レコードを特定する予約値（reserved value）を含む。
【００５７】
好ましくは、前記複数のアプリケーション・クラスの新たなインスタンスの各割り当てのために、前記新たなインスタンスの前記予約値内に、前記アプリケーション・プログラム・レコードの特定（identity）を記録する。
【００５８】
あるいは、前記アプリケーション・クラスは、自身のメモリ・レイアウト内に、自身が所属する前記アプリケーション・プログラム・レコードを特定する予約値を含む。
【００５９】
好ましくは、ガベージ・コレクション・イベントの間、各アプリケーション・プログラム・レコードのために、ガベージ・コレクションの間回収されない前記アプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの第二利用カウントを記録する。
【００６０】
好ましくは、ガベージ・コレクション・イベントの間又はその後、前記第一利用カウント値を、前記第二利用カウント値でアップデートする。
【００６１】
あるいは、ガベージ・コレクション・イベントの間、各アプリケーション・プログラム・レコードのために、ガベージ・コレクションの間回収されない前記複数のアプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの前記第一利用カウントをアップデートする。
【００６２】
上記は、本発明のいくつかの態様のみについて述べており、コンピュータ技術における当業者にとって明らかな複数の修正を、本発明の範囲を離れることなく、そこになすことが可能である。
【００６３】
ここで用いる「備える」なる用語（及びその複数の文法的バリエーション）は、「含む」又は「有する」なる包括的な意味合いで用いられ、「のみからなる」なる排他的な意味合いでは用いられない。
【００６４】
【表１Ａ】
2015519646.tif 000003
【００６５】
【表１Ｂ】
2015519646.tif 000004
【図１】
2015519646.tif 000005
【図２】
2015519646.tif 000006
【図３】
2015519646.tif 000007
【図４】
2015519646.tif 000008
【図５】
2015519646.tif 000009
【図６】
2015519646.tif 000010
【図７】
2015519646.tif 000011
【手続補正書】
【提出日】平成27年3月5日(2015.3.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
JVMの単一の実行インスタンス内で複数のJavaアプリケーションをホスティングするための修正されたJVMであって、前記JVMは、コンピュータのメモリ内に、一つ以上のアプリケーション・ドメインの記録を維持するよう変更され、各前記アプリケーション・ドメインは、一つ以上のアプリケーション・クラスを備え、各アプリケーション・ドメインのために、前記一つ以上のアプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの第一利用カウントが、前記コンピュータ・メモリ内で維持されることを特徴とする修正されたJVM。
【請求項２】
請求項１に記載の修正されたJVMであって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記第一利用カウントが、前記新たなインスタンスの占有メモリ・サイズと共に増加することを特徴とする、修正されたJVM。
【請求項３】
請求項１又は２に記載の修正されたJVMであって、前記第一利用カウントは、メモリのバイト数であることを特徴とする、修正されたJVM。
【請求項４】
請求項１乃至３のいずれか１項に記載の修正されたJVMであって、前記占有メモリ・サイズは、前記新たなインスタンスによって占有されるバイト単位でのメモリ・サイズであることを特徴とする、修正されたJVM。
【請求項５】
請求項１乃至４のいずれか１項に記載の修正されたJVMであって、前記割り当てられたインスタンスは、自身のメモリ・レイアウト内に、前記アプリケーション・クラスの前記アプリケーション・ドメインを特定する予約値（reserved value）を含むことを特徴とする、修正されたJVM。
【請求項６】
請求項１乃至５のいずれか１項に記載の修正されたJVMであって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記新たなインスタンスの前記予約値内に、前記アプリケーション・ドメインの前記特定の記録が作られることを特徴とする、修正されたJVM。
【請求項７】
請求項１乃至５のいずれか１項に記載の修正されたJVMであって、前記アプリケーション・クラスは、自身のメモリ・レイアウト内に、自身が属する前記アプリケーション・ドメインを特定する予約値を含むことを特徴とする、修正されたJVM。
【請求項８】
請求項１乃至７のいずれか１項に記載の修正されたJVMであって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられていたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの第二利用カウントを記録することを特徴とする、修正されたJVM。
【請求項９】
請求項１乃至８のいずれか１項に記載の修正されたJVMであって、ガベージ・コレクション・イベントの間に又はその後に、前記第一利用カウント値を、前記第二利用カウント値によりアップデートすることを特徴とする、修正されたJVM。
【請求項１０】
請求項１乃至８のいずれか１項に記載の修正されたJVMであって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの前記第一利用カウントをアップデートすることを特徴とする、修正されたJVM。
【請求項１１】
JVMの単一の実行インスタンス内で複数のJavaアプリケーションをホスティングするためにJVMを修正する方法であって、前記JVMは、コンピュータのメモリ内に、一つ以上のアプリケーション・ドメインの記録を維持するよう変更され、各前記アプリケーション・ドメインは、一つ以上のアプリケーション・クラスを備え、各アプリケーション・ドメインのために、前記一つ以上のアプリケーション・クラスの全ての割り当てられたインスタンスによって占有される総メモリの第一利用カウントが、前記コンピュータ・メモリ内で維持されることを特徴とするJVMを修正する方法。
【請求項１２】
請求項１１に記載のJVMを修正する方法であって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記第一利用カウントが、前記新たなインスタンスの占有メモリ・サイズと共に増加することを特徴とする、JVMを修正する方法。
【請求項１３】
請求項１１又は１２に記載のJVMを修正する方法であって、前記第一利用カウントは、メモリのバイト数であることを特徴とする、JVMを修正する方法。
【請求項１４】
請求項１１乃至１３のいずれか１項に記載のJVMを修正する方法であって、前記占有メモリ・サイズは、前記新たなインスタンスによって占有されるバイト単位でのメモリ・サイズであることを特徴とする、JVMを修正する方法。
【請求項１５】
請求項１１乃至１４のいずれか１項に記載のJVMを修正する方法であって、前記割り当てられたインスタンスは、自身のメモリ・レイアウト内に、前記アプリケーション・クラスの前記アプリケーション・ドメインを特定する予約値（reserved value）を含むことを特徴とする、JVMを修正する方法。
【請求項１６】
請求項１１乃至１５のいずれか１項に記載のJVMを修正する方法であって、前記アプリケーション・クラスの新たなインスタンスの各割り当てのために、前記新たなインスタンスの前記予約値内に、前記アプリケーション・ドメインの前記特定の記録が作られることを特徴とする、JVMを修正する方法。
【請求項１７】
請求項１１乃至１５のいずれか１項に記載のJVMを修正する方法であって、前記アプリケーション・クラスは、自身のメモリ・レイアウト内に、自身が属する前記アプリケーション・ドメインを特定する予約値を含むことを特徴とする、JVMを修正する方法。
【請求項１８】
請求項１１乃至１７のいずれか１項に記載のJVMを修正する方法であって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられていたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの第二利用カウントを記録することを特徴とする、JVMを修正する方法。
【請求項１９】
請求項１１乃至１８のいずれか１項に記載のJVMを修正する方法であって、ガベージ・コレクション・イベントの間に又はその後に、前記第一利用カウント値を、前記第二利用カウント値によりアップデートすることを特徴とする、JVMを修正する方法。
【請求項２０】
請求項１１乃至１８のいずれか１項に記載のJVMを修正する方法であって、ガベージ・コレクション・イベントの間に、各アプリケーション・ドメインのために、前記アプリケーション・クラスの全ての割り当てられたインスタンスのうちのガベージ・コレクションの間に回収されなかったものによって占有されていた総メモリの前記第一利用カウントをアップデートすることを特徴とする、JVMを修正する方法。
【国際調査報告】
2015519646.tif 000012
2015519646.tif 000013
2015519646.tif 000014