ランタイムメモリスロットリング

著者らは特許

G06F - 電気的デジタルデータ処理(特定の計算モデルに基づくコンピュータ・システムG06N)
G06F8/41 -
G06F9/455 - エミュレーション;ソフトウェアシミュレーション

の所有者の特許 JP2016528638:

オラクル・インターナショナル・コーポレイション

 

ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取るとメモリ管理ポリシーを実行時に実現するシステムは、構文ツリー内の複数のコールを識別し、複数のメモリ変更済みコールを作成するために、複数のコールの各々を対応するメモリ変更済みコールにより変更する。各メモリ変更済みコールはメモリ管理クラスとリンクされ、変更することは、ソフトウェアコードのコンパイル中に生じる。複数のコールの各々の変更に引続いて、システムは、複数のメモリ変更済みコールをコンパイルしてバイトコードを生成する。

 

 

関連する出願の相互参照
本願は、2013年8月15日付けで提出された仮特許出願番号第61/866,223号の優先権を主張し、その内容を引用によって本明細書に援用する。
分野
一実施形態は、概してコンピュータシステムに、特にソフトウェア命令をコンパイルするコンピュータシステムに向けられる。
背景情報
すべての種類のコンピュータシステムについて、メモリは限定されたリソースであり得る。コンピューティングシステムがどれほど高速になっても、ソフトウェアアプリケーションを実行するために有限量のメモリに常に依存している。その結果、ソフトウェア開発者は、ソフトウェアアプリケーションを書込んだり開発するときには、利用可能なメモリリソースを典型的に考慮する。
JAVA(登録商標)プログラミング言語は、一度書けばどこでも実行できる移植性、マルチスレッド化プログラミングのための移植可能サポート、リモートメソッド起動およびガベージコレクションを含む分散型プログラミングのサポートなどの、大規模分散型システムの開発者の興味を引くいくつかの特徴を呈する。しかしながら、JAVAは、メモリが割り当ておよび割り当て解除されるやり方が、多くの従来のプログラミング言語とは異なる。CおよびC++などの多くのプログラミング言語は、アプリケーションプログラマ/開発者によるメモリの割り当ておよび割り当て解除を明白に考慮に入れている。対照的に、JAVA仮想マシン(VM)は、JAVAアプリケーションのプログラマにとって故意に不透明な構造によってメモリを管理する。メモリを使い切ったあるスレッドは他の実行中のスレッドを壊す可能性があるため、この不透明性は、サーバVMなどの共用ユーザ環境においてスクリプトを実行する際に問題となる。このスレッド間コンタミネーション(contamination)は、JAVA VM全体をシャットダウンさせる可能性がある。
概要
一実施形態は、ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取るとメモリ管理ポリシーを実行時(runtime)に実現するシステムである。システムは、構文ツリー内の複数のコールを識別し、各複数のコールを対応するメモリ変更済みコールにより変更して、複数のメモリ変更済みコールを作成する。各メモリ変更済みコールはメモリ管理クラスとリンクされ、変更は、ソフトウェアコードのコンパイル中に生じる。複数のコールの各々の変更に引続いて、システムは、複数のメモリ変更済みコールをコンパイルしてバイトコードを生成する。
本発明の実施形態に係るコンピュータサーバ/システムのブロック図である。 一実施形態に従って実行時にメモリをスロットリングする際の図1のメモリスロットリングモジュールの機能のフローチャートである。 別の実施形態に従って実行時にメモリをスロットリングする際の図1のメモリスロットリングモジュールの機能のフローチャートである。 別の実施形態に従ってコンパイル中に変更された構文ツリーを用いて作成されたバイトコードを実行するための図1のメモリスロットリングモジュールの機能のフローチャートである。
詳細な説明
一実施形態は、メモリ内のプログラムをコンパイルしつつ、新たなオブジェクトを作成するすべてのコールを遮断し、JAVA VMメモリの注意事項/制約に鑑みて新たなオブジェクトを作成することができるかどうかをメモリポリシーに基づいて判定する。新たなオブジェクトの作成がメモリに悪影響を与えない場合は、オブジェクトを作成することができる。メモリ内オブジェクトの意図しない制御不能な作成(run-away creation)を阻止することによって、実施形態は、マルチユーザサーバ上で実行されるスクリプトをエンドユーザが入力することが可能となるシステムの安定性および性能を著しく向上させる。
図1は、本発明の実施形態に係るコンピュータサーバ/システム10のブロック図である。単一のシステムとして示されているが、システム10の機能は分散型システムとして実現することができる。さらに、本明細書に開示される機能は、ネットワークで互いに結合され得る別個のサーバまたは装置上で実現することができる。さらに、システム10の1つ以上のコンポーネントは含まれなくてもよい。たとえば、ユーザクライアントの機能について、システム10は、プロセッサ、メモリおよびディスプレイを含むスマートフォンであってもよいが、図1に示される他のコンポーネントのうち1つ以上を含まなくてもよい。
システム10は、情報を通信するためのバス12または他の通信機構と、情報を処理するためにバス12に結合されたプロセッサ22とを含む。プロセッサ22は、いずれかの種類の汎用または特定用途プロセッサであり得る。システム10は、情報とプロセッサ22によって実行される命令とを格納するためのメモリ14をさらに含む。メモリ14は、ランダムアクセスメモリ(RAM)、読取専用メモリ(ROM)、磁気もしくは光ディスクなどのスタティックストレージ、またはいずれかの他の種類のコンピュータ読取可能媒体のいずれかの組合せで構成することができる。システム10は、ネットワークへのアクセスを提供するために、ネットワークインターフェイスカードなどの通信装置20をさらに含む。したがって、ユーザは、直接的に、またはネットワークもしくはいずれかの他の方法によってリモートで、システム10と接続し得る。
コンピュータ読取可能媒体は、プロセッサ22によってアクセスすることができ、揮発性媒体および不揮発性媒体の両方、取外し可能な媒体および取外し不可能な媒体、ならびに通信媒体を含むいずれかの利用可能な媒体であり得る。通信媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、または搬送波もしくは他の移送機構などの変調されたデータ信号中の他のデータを含んでもよく、いずれかの情報配信媒体を含む。
プロセッサ22はさらに、バス12によって液晶ディスプレイ(LCD)などのディスプレイ24に結合される。キーボード26およびコンピュータマウスなどのカーソル制御デバイス28がバス12にさらに結合されて、ユーザがシステム10と接続することが可能となる。
一実施形態では、メモリ14は、プロセッサ22によって実行されると機能を提供するソフトウェアモジュールを格納する。モジュールは、オペレーティングシステム機能をシステム10に提供するオペレーティングシステム15を含む。モジュールは、実行時にメモリをスロットリングするためのメモリスロットリングモジュール16と、本明細書に開示されるすべての他の機能とをさらに含む。システム10は、より大きなシステムの一部であり得る。したがって、システム10は、1つ以上の付加的な機能モジュール18を含んで、付加的なGROOVY(登録商標)またはJAVA関連機能などの付加的な機能を含むことができる。データベース17はバス12に結合されて、モジュール16および18に集中記憶装置を提供する。
一実施形態は、コンパイルプロセス中に構文ツリーの変更を可能にするプログラミング言語を使用し、1つ以上のメモリスロットリングルール(以下「メモリポリシー」と称する)を実現する。一例として、ユーザは、コンパイルおよび実行のためにリモートコンピュータシステムからサーバにコードを送信し得る。このサーバは、ユーザとは別個の第三者によって操作されてもよく、第三者は、ある動作がユーザのコードによって行なわれることを防ぐメモリポリシーを強化することを所望し得る。(サーバに対してリモートまたはローカルな)ユーザによって送信されたコードはメモリポリシー機能を含んでいないことがあるが、サーバは、ユーザによって供給されたコードに基づいて構文ツリーにおけるメソッドコールを変更し得る。構文ツリーがコードに基づいて作成されると、構文ツリーの解析が行なわれ得る。解析は、メモリポリシーに従って厳しく禁止される様々なメソッド、コンストラクタアクセス、および/またはプロパティアクセスを識別することができる。メモリポリシーのこれらの妨害は、コードがバイトコードにコンパイルされるのを妨げることがあり、例外が出力されることになり得る。例外の表示はユーザに提示され得る。
一実施形態では、プログラミング言語は「GROOVY」プログラミング言語、またはバイトコード(またはマシンコード)が生成される前のコンパイルプロセス中に構文ツリーへのアクセスを許可する何らかの他のプログラミング言語である。GROOVYは、JAVAプラットフォームのためのオブジェクト指向プログラミング言語である。一般に、GROOVYはJAVAの上位セットであり、したがってJAVAコードはGROOVYにおいて構文的に有効である可能性がある。GROOVYは、JAVAにおいて利用可能なものに加えて、付加的な構文および特徴を含む。JAVAと同様に、GROOVYコードはバイトコードにコンパイルすることができる。このバイトコードは、仮想マシン(VM)によってマシンコードに変換することができる。
GROOVYコードがコンパイルされているとき、バイトコードが生成される前に、抽象構文ツリー(abstract syntax tree:AST)がコードに基づいて作成される。構文ツリーの形態にある間、実施形態は、バイトコードが作成される前にASTを編集する。したがって、バイトコードの作成、およびバイトコードが実行時にどのように実行することになるかに影響することになるASTに対して様々な変更をなすことができる。GROOVYを用いる代わりに、他の実施形態は、バイトコード(またはマシンコード)にコンパイルする前の構文ツリーレベルでのコードの編集を考慮に入れたいずれかのプログラミング言語を用いることができる。
一般に、GROOVYを用いる実施形態は以下の機能を含む。(1)(自動的にまたは手作業で)GROOVYコードに配置されるアノテーション(annotation)、(2)メソッドおよびプロパティアクセスの書直しを行なうAST操作クラス、および(3)実行時にメモリ制約を強化するオプションのQuotaPolicyクラス。3つの部分はすべて、用途(たとえば埋込み使用とスタンドアロン使用と)の違いを考慮に入れるために複数の重複する実現例を有することができる。
一実施形態のアノテーションは、標準的なGROOVY ASTアノテーションである。GROOVY AST操作クラスが呼出されるべきであることを、(コマンドラインまたはGroovyShell.parse()のいずれかによって呼出される)GROOVYコンパイラに通知するために用いられる。たとえば、ある種類のアノテーションをGROOVYスクリプトコードに用いることができる一方、別のものをGROOVYクラスコードに用いることができる。
Groovy AST操作はすべてのループコードを遮断し、それに新しいコードをラップする。これは、ループが何らかの許可されたメモリクォータ(つまりメモリポリシー)を越えたかどうかを判定する役割を担う。同様に、すべての収集クラスおよびストリングスがサイズについて監視され、作成され再びクォータに供されるメモリ集約的なオブジェクトの数を数えるために付加的なチェックが追加され得る。他の方法では無害のオブジェクトの組合せなどの不適当な量のシステムリソースを消費し得る他の動作について、付加的なチェックも追加され得る。AST操作が完了すれば、Java VM内のいずれかの他のクラスと同じように、メモリ不足に対する何らかの保証をもってクラスにアクセスすることができる。
クォータは、システム全体の識別されたプロパティによって、QuotaPolicyクラスの使用によって、スクリプトに関連付けられたメタデータによって、エンドユーザによりスクリプトに配置された変数によって、または何らかの他の方法もしくは方法の組合せによって、判定され得る。
図2は、一実施形態に従って実行時にメモリをスロットリングする際の図1のメモリスロットリングモジュール16の機能のフローチャートである。一実施形態では、図2のフローチャートの機能ならびに以下の図3および図4は、メモリまたは他のコンピュータ読取可能なもしくは有形の媒体に格納されたソフトウェアによって実現され、プロセッサによって実行される。他の実施形態では、当該機能は、(たとえば特定用途向け集積回路(ASIC)、プログラマブルゲートアレイ(PGA)、フィールドプログラマブルゲートアレイ(FPGA)等の使用により)ハードウェア、またはハードウェアおよびソフトウェアのいずれかの組合せによって行なわれ得る。
210において、構文ツリー内のコールが識別される。構文ツリーは、ユーザによって書込まれたかまたは他の方法で提供されたコードに基づいて作成された抽象構文ツリーであり得る。構文ツリーは、コードをコンパイルするプロセスの一部として作成され得る。いくつかのプログラミング言語では、構文ツリーが生成された後でコードを編集することが可能である。たとえば、GROOVYコードをコンパイルすることは、構文ツリーが生成された後であるがバイトコードが生成される前のコードの変更を可能にし得る。1つ以上の構文ツリー操作クラスが呼出されるべきであることを示す1つ以上のアノテーションをユーザがコードに追加している場合がある。メソッドコールを識別することに加え、コンストラクタコールおよび/またはプロパティアクセスコールが識別され得る。メソッドコール、コンストラクタコール、および/またはプロパティアクセスコール(コール)の識別は、構文ツリーを構文解析することによって遂行され得る。
220において、識別された各メソッドコールをメモリ変更済みコールで置換する。メソッドコールに加えて、コンストラクタコールおよび/またはプロパティアクセスコールもメモリ変更済みコールで置換され得る。メモリ変更済みコールは、以下に詳細に開示されるように、メモリポリシーに基づくコールの許可についてのチェックを生じさせる。コールをメモリ変更済みコールで置換することは、コールが実行される前に許可が付与されるかどうかを判定するためにメモリクラスが評価されるように、メモリクラスにコールを関連付けることを含み得る。たとえば、メソッドコールをメモリ変更済みメソッドコールで置換することは、メモリポリシーに対してメソッドコールがチェックされるようにメソッドコールがメモリクラスコールにおいてラップされるかまたは他の方法で変更されることを含み得る。メソッドコールはメモリクラスのパラメータとなり得、したがってメモリ変更済みメソッドコールを作成する。メモリチェックの結果、メソッドコールが許容可能であると識別された場合、メソッドコールのみが実行され得る。そのため、メモリポリシーに基づくメモリクラスは、メソッドコールが行なわれる前にメソッドコールを行なうための許可についてチェックされることになる。コンストラクタコールおよび/またはプロパティアクセスコールについて、同様の関連付けおよび/またはラッピングが生じ得る。
230において、置換に引続いて、1つ以上のメモリ変更済みメソッドコール、メモリ変更済みコンストラクタコール、および/またはメモリ変更済みプロパティアクセスコール(メモリ変更済みコール)を含み得る構文ツリーがコンパイルされる。変更済み構文ツリーのコンパイルの結果、マシンコードに解釈されて実行されるように構成されたバイトコードが作成されることになる。実行されると、各メモリ変更済みコールは、メモリクラスを用いてメモリポリシーに対してチェックされる。メモリ変更済みコールがメモリポリシーに合格しなければ、バイトコードは実行が中止され、例外が生成される。例外は、格納し、かつ/またはユーザに出力することができる。いくつかの実施形態では、違反しているメモリ変更済みコールをスキップし、バイトコードを実行し続けるよう試みることが可能であり得る。
図3は、別の実施形態に従って実行時にメモリをスロットリングする際の図1のメモリスロットリングモジュール16の機能のフローチャートである。
310において、メモリポリシーが受取られる。メモリポリシーは、過度のメモリ使用のために、コンパイルされたコードの実行中に許可されないことがあり、静的解析中に検出され得る一種のメソッドコール、コンストラクタコールおよび/またはプロパティアクセスコールを識別する1つ以上のメモリルールを含むことができる。メモリポリシーは、コードをコンパイルしているエンティティによって提供された、または当該エンティティに提供されたデフォルトメモリポリシーであってもよく、かつ/またはカスタマイズされたメモリポリシーであってもよい。一実施形態のメモリポリシーは、JAVA VMまたはそのライブラリ内の既存のメモリアレイのサイズの知識を使用し、サイズをより大きくすることができるかどうかを判定するか、またはすべての新たなオブジェクト作成を単一のアレイに限定する。メモリサイズの制約は、動的に調整し、変更することができる。
一実施形態のメモリポリシーは、コードをコンパイルして実行するシステムによって格納される。いくつかの実施形態では、メモリポリシーはリモートで格納され得るが、コードをコンパイルして実行するシステムにアクセス可能であり得る。
320において、コンパイルされていないコードが受取られる。このコードは、ユーザがコードを書込むかまたはコードを含む1つ以上のファイルを提供する形態で受取られ得る。いくつかの実施形態では、ユーザは、ユーザコンピュータシステムによって、コンパイルされ実行されるリモートサーバに、ウェブベースのインターフェイスを介してコードを送信し得る。リモートサーバは、コンパイルされていないコードを受取り、それをコンパイルし、ユーザコンピュータシステムからリモートコードを実行し得る。コードは、リモートユーザコンピュータシステムの他に、他のソースから受取られてもよい。
325において、コンパイルされていないコードに1つ以上のメモリ管理アノテーションが付加される。メモリ管理アノテーションは、(GROOVY AST操作クラスなどの)操作クラスが呼出されるべきであることをコンパイラに示す役割を果たす。スクリプトコード(たとえばGROOVYスクリプトコード)についてのアノテーションおよび/またはクラスコード(たとえばGROOVYクラスコード)についてのアノテーションを付加することができる。そのようなメモリ管理アノテーションは、ユーザにより手作業で、または自動的に、付加することができる。GROOVYを用いる実施形態では、メモリ管理アノテーションは、全文変形または局所変形のいずれかとして付加されてもよく、コマンドラインから、またはGroovyShell.parse()などのGROOVYアプリケーションプログラミングインターフェイス(API)からであり得るコンパイルステップでトリガされ得る。いくつかの実施形態では、アノテーションの代わりに、構成スイッチ、プロパティファイルまたは環境変数などの何らかの他のトリガ機構を用いることができる。
330において、コードのコンパイルが開始され、320で受取られたコンパイルされていないコードに基づいて抽象構文ツリーが作成される。ASTは、GROOVYなどのプログラミング言語で書かれた、320で受取られたコンパイルされていないコードのツリー表示である。ASTの各ノードは、一実施形態のコンパイルされていないコードの要素に対応する。GROOVYなどの、いくつかの実施形態について用いられるプログラミング言語は、バイトコード(またはマシンコード)をコンパイルするために構文ツリーが用いられる前に構文ツリーを編集することを許可する。
335において、構文ツリーを構文解析することによって、330で作成された構文ツリー内のコールが識別される。これは、メソッドコール、コンストラクタコールおよび/またはプロパティアクセスコールを含み得る。
340において、310で受取られたメモリポリシーを用いて、構文ツリーの静的解析を行なう。静的解析は、メモリポリシーを破ることになる(つまりメモリポリシー下で許可されない)1つ以上のコンストラクタコール、メソッドコール、および/またはプロパティアクセスコールを識別する。たとえば、大きいことが知られているエクステンシブル・マークアップ・ランゲージ(XML)ファイルを読出す際、メモリ内のドキュメント全体を保持するドキュメント・オブジェクト・モデル(DOM)法を用いることは、スクリプトのコンパイルの不許可をもたらす可能性がある。別の例として、非常に大きな静的ストリングオブジェクトのアレイを作成することも、大きいことが知られているファイルまたはデータベースからそれらのストリングスを読出すことができるように、スクリプトのコンパイルの不許可をもたらす可能性がある。
1つ以上のコンストラクタコール、メソッドコールおよび/またはプロパティアクセスコールが、メモリポリシーに従って許可可能ではない場合、機能は390まで継続する。
390において、340における1つ以上の不合格のコールに基づいて、メモリ例外が生成され、出力される。一実施形態では、320で受取られたコンパイルされていないコードがウェブインターフェイスによってユーザから受取られた場合、ウェブインターフェイスを用いて、当該1つ以上の不合格のコールをユーザに示すことができる。少なくともメモリ例外がコンパイルされていないコードにおいて訂正されるまで、バイトコードへの構文ツリーのコンパイルが阻止され得る。
340における静的解析がメモリポリシーに従っていずれのメモリ例外も識別しなければ、機能は370に続く。370において、335で識別された各メソッドコールについて、メソッドコール、コンストラクタコールおよび/またはプロパティアクセスコールを変更することによってメモリ変更済みメソッドコールが置換される。メソッドコールをメモリ変更済みメソッドコールで置換することは、メソッドコールが実行されることが許可されるかどうかを判定するためにメモリクラスが評価されるように、メモリクラスにメソッドコールを関連付けることを含む。メモリチェックの結果、メソッドコールが許可可能なものとして識別されることになった場合、メソッドコールのみが実行され得る。メソッドコールをメモリ変更済みメソッドコールで置換することは、メソッドコールがメモリクラスコールにおいてラップされることを含み得る。そのため、メモリクラスを用いて、メソッドコールが行なわれる前にメソッドコールを行なう許可についてチェックする。コンストラクタコールおよび/またはプロパティアクセスコールについて、同様の関連付けおよび/またはラッピングが生じ得る。いくつかの実施形態では、構文ツリーが構文解析されるにつれて、335および370の機能がともに行なわれる。たとえば、第1のメソッドコールは、第2のメソッドコールが識別される前に識別され、メモリ変更済みメソッドコールで置換され得る。
380において、370で置換が完了するのに引続いて、1つ以上のメモリ変更済みメソッドコール、メモリ変更済みコンストラクタコール、および/またはメモリ変更済みプロパティアクセスコールを含む構文ツリーがコンパイルされる。変更済み構文ツリーのコンパイルは、仮想マシンによってマシンコードに解釈されて実行されるように構成されたバイトコードをもたらす。いくつかの実施形態では、マシンコードは、コンパイラによって直接に作成されてもよい。
図4は、別の実施形態に係るコンパイル中に変更された構文ツリーを用いて作成されたバイトコードを実行するための図1のメモリスロットリングモジュール16の機能のフローチャートである。バイトコードは、図3の機能を用いて作成された可能性がある。図4の機能は、図1のシステム10とは別個のシステムによっても実行され得る。
410において、バイトコードの第1のメモリ変更済みコールが実行されるように試みられる。コールは、メモリ変更済みメソッドコール、メモリ変更済みコンストラクタアクセスコール、またはメモリ変更済みプロパティアクセスコールであり得る。実行される際、コールを直接実行するのではなく、コールに関連付けられたメモリクラスが用いられてもよい。
420において、メモリポリシーおよび既存のクォータに基づいて、メモリ変更済みコールについてのメモリチェックが行なわれる。コールがメモリポリシーに合格しなければ、機能は430において続く。430において、メモリ例外が生成され、出力される。バイトコードがさらに実行されることが妨げられる場合があり、ユーザに例外が通知される。
420においてコールがメモリポリシーを満たせば、440においてコールが実行される。したがって、図3の370においてメモリ変更済みコールを作成するために第1のコールが用いられた場合、メソッドコールがメモリポリシーと一致していれば、440において第1のコールが実行されることになる。440の実行が成功した場合に引続いて、機能は410に続き、別のメモリ変更済みコールが実行される。これは、バイトコードが完全に実行されるまで続くことになる。
開示されているように、実施形態はコンパイルコールを遮り、コンパイル中にメモリポリシーに基づいてコールを許可するか、またはコールを不許可とする。メモリ内オブジェクトの意図しない制御不能な作成を阻止することによって、実施形態は、JAVA VMを有するGROOVYなどの、マルチユーザサーバ上で実行されるスクリプトをエンドユーザが入力することを可能にするシステムの安定性および性能を著しく向上させることができる。実施形態はJAVA VMへの変更に依存しないため、現在実現されているJAVA VMで用いることができる。
いくつかの実施形態が本明細書に具体的に例示され、かつ/または説明される。しかしながら、開示した実施形態の変更および変形例は、発明の精神および意図される範囲から逸脱することなく、上記の教示によって添付の請求項の範囲内に包含されることが認識されるであろう。



  1. 命令が格納されたコンピュータ読取可能媒体であって、前記命令は、プロセッサによって実行されると、前記プロセッサにメモリ管理ポリシーを実行時に実現させ、前記実現は、
    ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取ることと、
    前記構文ツリー内の複数のコールを識別することと、
    複数のメモリ変更済みコールを作成するために、前記複数のコールの各々を対応するメモリ変更済みコールにより変更することとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更することは、前記ソフトウェアコードのコンパイル中に生じ、さらに、
    前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成することを含む、コンピュータ読取可能媒体。

  2. 前記複数のメモリ変更済みコールをコンパイルすることは、
    メモリ変更済みコールを実行することと、
    前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
    前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項1に記載のコンピュータ読取可能媒体。

  3. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項2に記載のコンピュータ読取可能媒体。

  4. 前記変更することは、コンパイルされていないソフトウェアコードに1つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項1に記載のコンピュータ読取可能媒体。

  5. 前記コンパイルされていないコードは、GROOVY言語として書込まれる、請求項1に記載のコンピュータ読取可能媒体。

  6. 前記バイトコードは、JAVA仮想マシンによってマシンコードに変換される、請求項1に記載のコンピュータ読取可能媒体。

  7. 前記メモリポリシーは、JAVAメモリ制約に基づく、請求項2に記載のコンピュータ読取可能媒体。

  8. 前記ソフトウェアコードは、リモートの相手から受取られる、請求項1に記載のコンピュータ読取可能媒体。

  9. メモリ管理ポリシーを実行時に実現する方法であって、当該方法は、
    ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取ることと、
    前記構文ツリー内の複数のコールを識別することと、
    複数のメモリ変更済みコールを作成するために、前記複数のコールの各々を対応するメモリ変更済みコールにより変更することとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更することは、前記ソフトウェアコードのコンパイル中に生じ、さらに、
    前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成することを含む、方法。

  10. 前記複数のメモリ変更済みコールをコンパイルすることは、
    メモリ変更済みコールを実行することと、
    前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
    前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項9に記載の方法。

  11. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項9に記載の方法。

  12. 前記変更することは、コンパイルされていないソフトウェアコードに1つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項9に記載の方法。

  13. 前記コンパイルされていないコードは、GROOVY言語として書込まれる、請求項9に記載の方法。

  14. 前記バイトコードは、JAVA仮想マシンによってマシンコードに変換される、請求項9に記載の方法。

  15. 前記メモリポリシーは、JAVAメモリ制約に基づく、請求項10に記載の方法。

  16. ソフトウェアコンパイラであって、
    プロセッサと、
    前記プロセッサに結合され、前記プロセッサによって実行されるとモジュールを生成する命令を格納するメモリ装置とを備え、前記モジュールは、
    ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取り、前記構文ツリー内の複数のコールを識別する識別モジュールと、
    複数のメモリ変更済みコールを作成するために前記複数のコールの各々を対応するメモリ変更済みコールにより変更する変更モジュールとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更は、前記ソフトウェアコードのコンパイル中に生じ、さらに、
    前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成するコンパイラモジュールを含む、ソフトウェアコンパイラ。

  17. 前記複数のメモリ変更済みコールをコンパイルすることは、
    メモリ変更済みコールを実行することと、
    前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
    前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項16に記載のソフトウェアコンパイラ。

  18. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項17に記載のソフトウェアコンパイラ。

  19. 前記変更することは、コンパイルされていないソフトウェアコードに1つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項16に記載のソフトウェアコンパイラ。

  20. 前記コンパイルされていないコードは、GROOVY言語として書込まれる、請求項16に記載のソフトウェアコンパイラ。

  21. 前記バイトコードは、JAVA仮想マシンによってマシンコードに変換される、請求項16に記載のソフトウェアコンパイラ。

 

 

Patent trol of patentswamp
類似の特許
自動プロセスを動作させるシステムを提供する。前記システムは、データベース(106)に対して通信可能に接続された第1コンピュータ(102)を備える。前記第1コンピュータ(102)は、前記データベース(106)が格納しているデータを利用して、自動プロセスの動作に対して影響する命令を実行するように構成されている。さらに、自動プロセスを動作させる方法を提供する。前記方法は、データベース(106)に対して通信可能に接続された第1コンピュータ(102)を提供するステップ;自動プロセスを実行するように前記第1コンピュータ(102)を構成するステップ;前記データベース(106)が格納しているデータを用いて前記自動プロセスを実行するステップ、を有する。
【選択図】図1
コードの仮想化およびリモートプロセスコールコード生成のためのシステムおよび方法。ユーザデバイスにソフトウェア開発キットをインストールするステップと、リモートサーバ上のリモートプロセスを選択するステップであって、リモートプロセスは、少なくとも1つのリモートサービスと相関される、ステップとを含む方法。また、リモートプロセスに対して事前定義されたフィールドからパラメータを解析し、リモートサーバ上で少なくとも1つの仮想コードプロバイダによってリモートプロセスを呼び出すためのコードスニペットを生成する方法。挿入されたコードスニペットは、インストールされたsdkを用いてリモートプロセスを呼び出すように、ローカルユーザデバイスのローカルコードベースにコードスニペットを挿入する方法。
データセンタにおいて計算インスタンスを事前準備するためのシステム、方法およびコンピュータ可読媒体が記述される。データセンタに関連するサービスプロバイダは、計算インスタンスについての要求を予測し、データセンタ内のコンピューティングリソースを事前設定することによって、計算インスタンスを事前起動することができる。そのようなものとして、ユーザが計算インスタンスをリクエストすると、サービスプロバイダは、事前準備された計算インスタンスをユーザに割り当てることによって、リクエストを満たすことができる。
本発明は、端末デバイスのアプリケーションシナリオを識別する方法を開示するものであり、この方法は、コンパイルすることによって、端末デバイス上で実行中のアプリケーションプログラムを分析して、アプリケーションプログラムの特徴データを取得するステップと、アプリケーションプログラムの特徴データに従って、シナリオの特徴データの組から、アプリケーションプログラムの特徴データに対応するアプリケーションシナリオ情報を求めるステップであって、シナリオの特徴データの組が、複数のタイプのアプリケーションシナリオ情報と複数のアプリケーションプログラムの特徴データの間の対応を含み、アプリケーションプログラムの特徴データに対応するアプリケーションシナリオ情報が、端末デバイスに現在用いられているアプリケーションシナリオを示すのに用いられる、ステップとを含む。本発明の実施形態は、電力消費の管理方法をさらに提供するものである。アプリケーションプログラムの特徴データが、対応するアプリケーションシナリオを説明することにおいて一意である可能性が高いので、アプリケーションプログラムの特徴データに対応するアプリケーションシナリオ情報が比較的正確である。したがって、本発明の実施形態により、端末デバイスのアプリケーションシナリオが比較的正確に識別され得る。
ハドゥープアプリケーションおよび仮想環境内で実行される他の作業負荷の高弾力性マルチテナントプラットホームを提供する分散計算アプリケーションについて説明する。ハドゥープなどの分散計算フレームワークの複数のインスタンスは同時に実行され得る。中央集中型マネジャは、メモリおよびCPUなどの計算資源の競合により、タスクが、所与のホスト上で実行するVM上でより遅く実行される時を検知し、かつ検知された資源競合に基づきクラスタを拡大または縮小する。
コンピューティング・リソースの機器構成がユーザの代わりに仮想マシンを実行して暗号的に証明されるかあるいは確認することができるようにする手法。ユーザが、仮想マシンをプロビジョニングしてもらうことを要求するとき、仮想化されたコンピューティング環境のオペレータは仮想マシンの2段階立ち上げを開始することができる。第1段階では、オペレータは、ホスト・コンピューティング・デバイス上の仮想マシンをプロビジョニングし、ホスト・コンピューティング・デバイス上のソフトウェア及び/またはハードウェアのリソースの暗号測定を得る。その後、オペレータは、仮想マシンを要求したユーザにこれらの暗号測定を提供することができる。ユーザが暗号測定を承認すれば、オペレータは第2段階を始めて、実際に、ホスト上で仮想マシンを立ち上げることができる。ある場合には、オペレータは、暗号測定と承認された測定のリストとを比較してホスト・コンピューティング・デバイスが仮想マシンのホスティングに受け入れ可能かどうかを判断することができる。
【選択図】図6
記載するシステムおよび方法は、ウイルスおよびルートキットなどのマルウェアからコンピュータシステムを保護することを可能にする。アンチマルウェアコンポーネントが、コンピュータシステムで実行されるハイパーバイザによって公開される仮想マシン(VM)内で実行される。メモリ内部監視エンジンが、ハイパーバイザのプロセッサ特権レベルで、仮想マシンの外で実行され、それぞれのプロセスのメモリページを書き込み保護することによって、仮想マシン内で実行されるプロセスを保護する。それぞれのVM内および外で実行されるアンチマルウェアコンポーネントを結合することによって、本発明のいくつかの実施形態は、VM内のコンポーネントがアクセスできる豊富な挙動データを使用すると同時に、それぞれのVMの外からそのようなコンポーネントの整合性を保護することができる。
本開示の実施形態は、輻輳を測定し、共有リソースへのサービス品質を制御する技法を提供する。共有リソースとインターフェースするモジュールは、クライアントにアクセスすることによって共有リソースの使用をモニタする。共有リソースの使用率が共有リソースによってサポートされる最大率を超えたことが検出されると、モジュールは、輻輳メトリックを特定し、共有リソースへのアクセスを現在試みているクライアントに輻輳メトリックを送信する。そして、クライアントは、共有リソースの別のアクセスを試みる前に、輻輳メトリックに基づいて遅延期間を決定する。
記載するシステムおよび方法は、仮想化技術を使用してマルウェアからホストシステムを保護することを可能にする。いくつかの実施形態では、メモリ内部監視エンジンが、ホストシステムで実行される仮想マシン(VM)の下で動作する。エンジンは、VM内で実行されるソフトウェアによって使用される仮想メモリページの内容を分析する、および/またはたとえばマルウェアによる許可されていない変更からそれぞれの内容を保護するように構成される。それぞれの内容がメモリからスワップアウトされているとき、メモリ内部監視エンジンは、それぞれのVMにページフォールトをインジェクトして、それぞれの内容のスワップインを強制する。
To top