JP2016528638A - ランタイムメモリスロットリング - Google Patents

Abstract

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

Description

関連する出願の相互参照
本願は、２０１３年８月１５日付けで提出された仮特許出願番号第６１／８６６，２２３号の優先権を主張し、その内容を引用によって本明細書に援用する。

分野
一実施形態は、概してコンピュータシステムに、特にソフトウェア命令をコンパイルするコンピュータシステムに向けられる。

背景情報
すべての種類のコンピュータシステムについて、メモリは限定されたリソースであり得る。コンピューティングシステムがどれほど高速になっても、ソフトウェアアプリケーションを実行するために有限量のメモリに常に依存している。その結果、ソフトウェア開発者は、ソフトウェアアプリケーションを書込んだり開発するときには、利用可能なメモリリソースを典型的に考慮する。

ＪＡＶＡ（登録商標）プログラミング言語は、一度書けばどこでも実行できる移植性、マルチスレッド化プログラミングのための移植可能サポート、リモートメソッド起動およびガベージコレクションを含む分散型プログラミングのサポートなどの、大規模分散型システムの開発者の興味を引くいくつかの特徴を呈する。しかしながら、ＪＡＶＡは、メモリが割り当ておよび割り当て解除されるやり方が、多くの従来のプログラミング言語とは異なる。ＣおよびＣ＋＋などの多くのプログラミング言語は、アプリケーションプログラマ／開発者によるメモリの割り当ておよび割り当て解除を明白に考慮に入れている。対照的に、ＪＡＶＡ仮想マシン（ＶＭ）は、ＪＡＶＡアプリケーションのプログラマにとって故意に不透明な構造によってメモリを管理する。メモリを使い切ったあるスレッドは他の実行中のスレッドを壊す可能性があるため、この不透明性は、サーバＶＭなどの共用ユーザ環境においてスクリプトを実行する際に問題となる。このスレッド間コンタミネーション（contamination）は、ＪＡＶＡ ＶＭ全体をシャットダウンさせる可能性がある。

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

本発明の実施形態に係るコンピュータサーバ／システムのブロック図である。 一実施形態に従って実行時にメモリをスロットリングする際の図１のメモリスロットリングモジュールの機能のフローチャートである。 別の実施形態に従って実行時にメモリをスロットリングする際の図１のメモリスロットリングモジュールの機能のフローチャートである。 別の実施形態に従ってコンパイル中に変更された構文ツリーを用いて作成されたバイトコードを実行するための図１のメモリスロットリングモジュールの機能のフローチャートである。

詳細な説明
一実施形態は、メモリ内のプログラムをコンパイルしつつ、新たなオブジェクトを作成するすべてのコールを遮断し、ＪＡＶＡ ＶＭメモリの注意事項／制約に鑑みて新たなオブジェクトを作成することができるかどうかをメモリポリシーに基づいて判定する。新たなオブジェクトの作成がメモリに悪影響を与えない場合は、オブジェクトを作成することができる。メモリ内オブジェクトの意図しない制御不能な作成（run-away creation）を阻止することによって、実施形態は、マルチユーザサーバ上で実行されるスクリプトをエンドユーザが入力することが可能となるシステムの安定性および性能を著しく向上させる。

図１は、本発明の実施形態に係るコンピュータサーバ／システム１０のブロック図である。単一のシステムとして示されているが、システム１０の機能は分散型システムとして実現することができる。さらに、本明細書に開示される機能は、ネットワークで互いに結合され得る別個のサーバまたは装置上で実現することができる。さらに、システム１０の１つ以上のコンポーネントは含まれなくてもよい。たとえば、ユーザクライアントの機能について、システム１０は、プロセッサ、メモリおよびディスプレイを含むスマートフォンであってもよいが、図１に示される他のコンポーネントのうち１つ以上を含まなくてもよい。

システム１０は、情報を通信するためのバス１２または他の通信機構と、情報を処理するためにバス１２に結合されたプロセッサ２２とを含む。プロセッサ２２は、いずれかの種類の汎用または特定用途プロセッサであり得る。システム１０は、情報とプロセッサ２２によって実行される命令とを格納するためのメモリ１４をさらに含む。メモリ１４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、磁気もしくは光ディスクなどのスタティックストレージ、またはいずれかの他の種類のコンピュータ読取可能媒体のいずれかの組合せで構成することができる。システム１０は、ネットワークへのアクセスを提供するために、ネットワークインターフェイスカードなどの通信装置２０をさらに含む。したがって、ユーザは、直接的に、またはネットワークもしくはいずれかの他の方法によってリモートで、システム１０と接続し得る。

コンピュータ読取可能媒体は、プロセッサ２２によってアクセスすることができ、揮発性媒体および不揮発性媒体の両方、取外し可能な媒体および取外し不可能な媒体、ならびに通信媒体を含むいずれかの利用可能な媒体であり得る。通信媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、または搬送波もしくは他の移送機構などの変調されたデータ信号中の他のデータを含んでもよく、いずれかの情報配信媒体を含む。

プロセッサ２２はさらに、バス１２によって液晶ディスプレイ（ＬＣＤ）などのディスプレイ２４に結合される。キーボード２６およびコンピュータマウスなどのカーソル制御デバイス２８がバス１２にさらに結合されて、ユーザがシステム１０と接続することが可能となる。

一実施形態では、メモリ１４は、プロセッサ２２によって実行されると機能を提供するソフトウェアモジュールを格納する。モジュールは、オペレーティングシステム機能をシステム１０に提供するオペレーティングシステム１５を含む。モジュールは、実行時にメモリをスロットリングするためのメモリスロットリングモジュール１６と、本明細書に開示されるすべての他の機能とをさらに含む。システム１０は、より大きなシステムの一部であり得る。したがって、システム１０は、１つ以上の付加的な機能モジュール１８を含んで、付加的なＧＲＯＯＶＹ（登録商標）またはＪＡＶＡ関連機能などの付加的な機能を含むことができる。データベース１７はバス１２に結合されて、モジュール１６および１８に集中記憶装置を提供する。

一実施形態は、コンパイルプロセス中に構文ツリーの変更を可能にするプログラミング言語を使用し、１つ以上のメモリスロットリングルール（以下「メモリポリシー」と称する）を実現する。一例として、ユーザは、コンパイルおよび実行のためにリモートコンピュータシステムからサーバにコードを送信し得る。このサーバは、ユーザとは別個の第三者によって操作されてもよく、第三者は、ある動作がユーザのコードによって行なわれることを防ぐメモリポリシーを強化することを所望し得る。（サーバに対してリモートまたはローカルな）ユーザによって送信されたコードはメモリポリシー機能を含んでいないことがあるが、サーバは、ユーザによって供給されたコードに基づいて構文ツリーにおけるメソッドコールを変更し得る。構文ツリーがコードに基づいて作成されると、構文ツリーの解析が行なわれ得る。解析は、メモリポリシーに従って厳しく禁止される様々なメソッド、コンストラクタアクセス、および／またはプロパティアクセスを識別することができる。メモリポリシーのこれらの妨害は、コードがバイトコードにコンパイルされるのを妨げることがあり、例外が出力されることになり得る。例外の表示はユーザに提示され得る。

一実施形態では、プログラミング言語は「ＧＲＯＯＶＹ」プログラミング言語、またはバイトコード（またはマシンコード）が生成される前のコンパイルプロセス中に構文ツリーへのアクセスを許可する何らかの他のプログラミング言語である。ＧＲＯＯＶＹは、ＪＡＶＡプラットフォームのためのオブジェクト指向プログラミング言語である。一般に、ＧＲＯＯＶＹはＪＡＶＡの上位セットであり、したがってＪＡＶＡコードはＧＲＯＯＶＹにおいて構文的に有効である可能性がある。ＧＲＯＯＶＹは、ＪＡＶＡにおいて利用可能なものに加えて、付加的な構文および特徴を含む。ＪＡＶＡと同様に、ＧＲＯＯＶＹコードはバイトコードにコンパイルすることができる。このバイトコードは、仮想マシン（ＶＭ）によってマシンコードに変換することができる。

ＧＲＯＯＶＹコードがコンパイルされているとき、バイトコードが生成される前に、抽象構文ツリー（abstract syntax tree：ＡＳＴ）がコードに基づいて作成される。構文ツリーの形態にある間、実施形態は、バイトコードが作成される前にＡＳＴを編集する。したがって、バイトコードの作成、およびバイトコードが実行時にどのように実行することになるかに影響することになるＡＳＴに対して様々な変更をなすことができる。ＧＲＯＯＶＹを用いる代わりに、他の実施形態は、バイトコード（またはマシンコード）にコンパイルする前の構文ツリーレベルでのコードの編集を考慮に入れたいずれかのプログラミング言語を用いることができる。

一般に、ＧＲＯＯＶＹを用いる実施形態は以下の機能を含む。（１）（自動的にまたは手作業で）ＧＲＯＯＶＹコードに配置されるアノテーション（annotation）、（２）メソッドおよびプロパティアクセスの書直しを行なうＡＳＴ操作クラス、および（３）実行時にメモリ制約を強化するオプションのＱｕｏｔａＰｏｌｉｃｙクラス。３つの部分はすべて、用途（たとえば埋込み使用とスタンドアロン使用と）の違いを考慮に入れるために複数の重複する実現例を有することができる。

一実施形態のアノテーションは、標準的なＧＲＯＯＶＹ ＡＳＴアノテーションである。ＧＲＯＯＶＹ ＡＳＴ操作クラスが呼出されるべきであることを、（コマンドラインまたはGroovyShell.parse()のいずれかによって呼出される）ＧＲＯＯＶＹコンパイラに通知するために用いられる。たとえば、ある種類のアノテーションをＧＲＯＯＶＹスクリプトコードに用いることができる一方、別のものをＧＲＯＯＶＹクラスコードに用いることができる。

Ｇｒｏｏｖｙ ＡＳＴ操作はすべてのループコードを遮断し、それに新しいコードをラップする。これは、ループが何らかの許可されたメモリクォータ（つまりメモリポリシー）を越えたかどうかを判定する役割を担う。同様に、すべての収集クラスおよびストリングスがサイズについて監視され、作成され再びクォータに供されるメモリ集約的なオブジェクトの数を数えるために付加的なチェックが追加され得る。他の方法では無害のオブジェクトの組合せなどの不適当な量のシステムリソースを消費し得る他の動作について、付加的なチェックも追加され得る。ＡＳＴ操作が完了すれば、Ｊａｖａ ＶＭ内のいずれかの他のクラスと同じように、メモリ不足に対する何らかの保証をもってクラスにアクセスすることができる。

クォータは、システム全体の識別されたプロパティによって、ＱｕｏｔａＰｏｌｉｃｙクラスの使用によって、スクリプトに関連付けられたメタデータによって、エンドユーザによりスクリプトに配置された変数によって、または何らかの他の方法もしくは方法の組合せによって、判定され得る。

図２は、一実施形態に従って実行時にメモリをスロットリングする際の図１のメモリスロットリングモジュール１６の機能のフローチャートである。一実施形態では、図２のフローチャートの機能ならびに以下の図３および図４は、メモリまたは他のコンピュータ読取可能なもしくは有形の媒体に格納されたソフトウェアによって実現され、プロセッサによって実行される。他の実施形態では、当該機能は、（たとえば特定用途向け集積回路（ＡＳＩＣ）、プログラマブルゲートアレイ（ＰＧＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の使用により）ハードウェア、またはハードウェアおよびソフトウェアのいずれかの組合せによって行なわれ得る。

２１０において、構文ツリー内のコールが識別される。構文ツリーは、ユーザによって書込まれたかまたは他の方法で提供されたコードに基づいて作成された抽象構文ツリーであり得る。構文ツリーは、コードをコンパイルするプロセスの一部として作成され得る。いくつかのプログラミング言語では、構文ツリーが生成された後でコードを編集することが可能である。たとえば、ＧＲＯＯＶＹコードをコンパイルすることは、構文ツリーが生成された後であるがバイトコードが生成される前のコードの変更を可能にし得る。１つ以上の構文ツリー操作クラスが呼出されるべきであることを示す１つ以上のアノテーションをユーザがコードに追加している場合がある。メソッドコールを識別することに加え、コンストラクタコールおよび／またはプロパティアクセスコールが識別され得る。メソッドコール、コンストラクタコール、および／またはプロパティアクセスコール（コール）の識別は、構文ツリーを構文解析することによって遂行され得る。

２２０において、識別された各メソッドコールをメモリ変更済みコールで置換する。メソッドコールに加えて、コンストラクタコールおよび／またはプロパティアクセスコールもメモリ変更済みコールで置換され得る。メモリ変更済みコールは、以下に詳細に開示されるように、メモリポリシーに基づくコールの許可についてのチェックを生じさせる。コールをメモリ変更済みコールで置換することは、コールが実行される前に許可が付与されるかどうかを判定するためにメモリクラスが評価されるように、メモリクラスにコールを関連付けることを含み得る。たとえば、メソッドコールをメモリ変更済みメソッドコールで置換することは、メモリポリシーに対してメソッドコールがチェックされるようにメソッドコールがメモリクラスコールにおいてラップされるかまたは他の方法で変更されることを含み得る。メソッドコールはメモリクラスのパラメータとなり得、したがってメモリ変更済みメソッドコールを作成する。メモリチェックの結果、メソッドコールが許容可能であると識別された場合、メソッドコールのみが実行され得る。そのため、メモリポリシーに基づくメモリクラスは、メソッドコールが行なわれる前にメソッドコールを行なうための許可についてチェックされることになる。コンストラクタコールおよび／またはプロパティアクセスコールについて、同様の関連付けおよび／またはラッピングが生じ得る。

２３０において、置換に引続いて、１つ以上のメモリ変更済みメソッドコール、メモリ変更済みコンストラクタコール、および／またはメモリ変更済みプロパティアクセスコール（メモリ変更済みコール）を含み得る構文ツリーがコンパイルされる。変更済み構文ツリーのコンパイルの結果、マシンコードに解釈されて実行されるように構成されたバイトコードが作成されることになる。実行されると、各メモリ変更済みコールは、メモリクラスを用いてメモリポリシーに対してチェックされる。メモリ変更済みコールがメモリポリシーに合格しなければ、バイトコードは実行が中止され、例外が生成される。例外は、格納し、かつ／またはユーザに出力することができる。いくつかの実施形態では、違反しているメモリ変更済みコールをスキップし、バイトコードを実行し続けるよう試みることが可能であり得る。

図３は、別の実施形態に従って実行時にメモリをスロットリングする際の図１のメモリスロットリングモジュール１６の機能のフローチャートである。

３１０において、メモリポリシーが受取られる。メモリポリシーは、過度のメモリ使用のために、コンパイルされたコードの実行中に許可されないことがあり、静的解析中に検出され得る一種のメソッドコール、コンストラクタコールおよび／またはプロパティアクセスコールを識別する１つ以上のメモリルールを含むことができる。メモリポリシーは、コードをコンパイルしているエンティティによって提供された、または当該エンティティに提供されたデフォルトメモリポリシーであってもよく、かつ／またはカスタマイズされたメモリポリシーであってもよい。一実施形態のメモリポリシーは、ＪＡＶＡ ＶＭまたはそのライブラリ内の既存のメモリアレイのサイズの知識を使用し、サイズをより大きくすることができるかどうかを判定するか、またはすべての新たなオブジェクト作成を単一のアレイに限定する。メモリサイズの制約は、動的に調整し、変更することができる。

一実施形態のメモリポリシーは、コードをコンパイルして実行するシステムによって格納される。いくつかの実施形態では、メモリポリシーはリモートで格納され得るが、コードをコンパイルして実行するシステムにアクセス可能であり得る。

３２０において、コンパイルされていないコードが受取られる。このコードは、ユーザがコードを書込むかまたはコードを含む１つ以上のファイルを提供する形態で受取られ得る。いくつかの実施形態では、ユーザは、ユーザコンピュータシステムによって、コンパイルされ実行されるリモートサーバに、ウェブベースのインターフェイスを介してコードを送信し得る。リモートサーバは、コンパイルされていないコードを受取り、それをコンパイルし、ユーザコンピュータシステムからリモートコードを実行し得る。コードは、リモートユーザコンピュータシステムの他に、他のソースから受取られてもよい。

３２５において、コンパイルされていないコードに１つ以上のメモリ管理アノテーションが付加される。メモリ管理アノテーションは、（ＧＲＯＯＶＹ ＡＳＴ操作クラスなどの）操作クラスが呼出されるべきであることをコンパイラに示す役割を果たす。スクリプトコード（たとえばＧＲＯＯＶＹスクリプトコード）についてのアノテーションおよび／またはクラスコード（たとえばＧＲＯＯＶＹクラスコード）についてのアノテーションを付加することができる。そのようなメモリ管理アノテーションは、ユーザにより手作業で、または自動的に、付加することができる。ＧＲＯＯＶＹを用いる実施形態では、メモリ管理アノテーションは、全文変形または局所変形のいずれかとして付加されてもよく、コマンドラインから、またはGroovyShell.parse()などのＧＲＯＯＶＹアプリケーションプログラミングインターフェイス（ＡＰＩ）からであり得るコンパイルステップでトリガされ得る。いくつかの実施形態では、アノテーションの代わりに、構成スイッチ、プロパティファイルまたは環境変数などの何らかの他のトリガ機構を用いることができる。

３３０において、コードのコンパイルが開始され、３２０で受取られたコンパイルされていないコードに基づいて抽象構文ツリーが作成される。ＡＳＴは、ＧＲＯＯＶＹなどのプログラミング言語で書かれた、３２０で受取られたコンパイルされていないコードのツリー表示である。ＡＳＴの各ノードは、一実施形態のコンパイルされていないコードの要素に対応する。ＧＲＯＯＶＹなどの、いくつかの実施形態について用いられるプログラミング言語は、バイトコード（またはマシンコード）をコンパイルするために構文ツリーが用いられる前に構文ツリーを編集することを許可する。

３３５において、構文ツリーを構文解析することによって、３３０で作成された構文ツリー内のコールが識別される。これは、メソッドコール、コンストラクタコールおよび／またはプロパティアクセスコールを含み得る。

３４０において、３１０で受取られたメモリポリシーを用いて、構文ツリーの静的解析を行なう。静的解析は、メモリポリシーを破ることになる（つまりメモリポリシー下で許可されない）１つ以上のコンストラクタコール、メソッドコール、および／またはプロパティアクセスコールを識別する。たとえば、大きいことが知られているエクステンシブル・マークアップ・ランゲージ（ＸＭＬ）ファイルを読出す際、メモリ内のドキュメント全体を保持するドキュメント・オブジェクト・モデル（ＤＯＭ）法を用いることは、スクリプトのコンパイルの不許可をもたらす可能性がある。別の例として、非常に大きな静的ストリングオブジェクトのアレイを作成することも、大きいことが知られているファイルまたはデータベースからそれらのストリングスを読出すことができるように、スクリプトのコンパイルの不許可をもたらす可能性がある。

１つ以上のコンストラクタコール、メソッドコールおよび／またはプロパティアクセスコールが、メモリポリシーに従って許可可能ではない場合、機能は３９０まで継続する。

３９０において、３４０における１つ以上の不合格のコールに基づいて、メモリ例外が生成され、出力される。一実施形態では、３２０で受取られたコンパイルされていないコードがウェブインターフェイスによってユーザから受取られた場合、ウェブインターフェイスを用いて、当該１つ以上の不合格のコールをユーザに示すことができる。少なくともメモリ例外がコンパイルされていないコードにおいて訂正されるまで、バイトコードへの構文ツリーのコンパイルが阻止され得る。

３４０における静的解析がメモリポリシーに従っていずれのメモリ例外も識別しなければ、機能は３７０に続く。３７０において、３３５で識別された各メソッドコールについて、メソッドコール、コンストラクタコールおよび／またはプロパティアクセスコールを変更することによってメモリ変更済みメソッドコールが置換される。メソッドコールをメモリ変更済みメソッドコールで置換することは、メソッドコールが実行されることが許可されるかどうかを判定するためにメモリクラスが評価されるように、メモリクラスにメソッドコールを関連付けることを含む。メモリチェックの結果、メソッドコールが許可可能なものとして識別されることになった場合、メソッドコールのみが実行され得る。メソッドコールをメモリ変更済みメソッドコールで置換することは、メソッドコールがメモリクラスコールにおいてラップされることを含み得る。そのため、メモリクラスを用いて、メソッドコールが行なわれる前にメソッドコールを行なう許可についてチェックする。コンストラクタコールおよび／またはプロパティアクセスコールについて、同様の関連付けおよび／またはラッピングが生じ得る。いくつかの実施形態では、構文ツリーが構文解析されるにつれて、３３５および３７０の機能がともに行なわれる。たとえば、第１のメソッドコールは、第２のメソッドコールが識別される前に識別され、メモリ変更済みメソッドコールで置換され得る。

３８０において、３７０で置換が完了するのに引続いて、１つ以上のメモリ変更済みメソッドコール、メモリ変更済みコンストラクタコール、および／またはメモリ変更済みプロパティアクセスコールを含む構文ツリーがコンパイルされる。変更済み構文ツリーのコンパイルは、仮想マシンによってマシンコードに解釈されて実行されるように構成されたバイトコードをもたらす。いくつかの実施形態では、マシンコードは、コンパイラによって直接に作成されてもよい。

図４は、別の実施形態に係るコンパイル中に変更された構文ツリーを用いて作成されたバイトコードを実行するための図１のメモリスロットリングモジュール１６の機能のフローチャートである。バイトコードは、図３の機能を用いて作成された可能性がある。図４の機能は、図１のシステム１０とは別個のシステムによっても実行され得る。

４１０において、バイトコードの第１のメモリ変更済みコールが実行されるように試みられる。コールは、メモリ変更済みメソッドコール、メモリ変更済みコンストラクタアクセスコール、またはメモリ変更済みプロパティアクセスコールであり得る。実行される際、コールを直接実行するのではなく、コールに関連付けられたメモリクラスが用いられてもよい。

４２０において、メモリポリシーおよび既存のクォータに基づいて、メモリ変更済みコールについてのメモリチェックが行なわれる。コールがメモリポリシーに合格しなければ、機能は４３０において続く。４３０において、メモリ例外が生成され、出力される。バイトコードがさらに実行されることが妨げられる場合があり、ユーザに例外が通知される。

４２０においてコールがメモリポリシーを満たせば、４４０においてコールが実行される。したがって、図３の３７０においてメモリ変更済みコールを作成するために第１のコールが用いられた場合、メソッドコールがメモリポリシーと一致していれば、４４０において第１のコールが実行されることになる。４４０の実行が成功した場合に引続いて、機能は４１０に続き、別のメモリ変更済みコールが実行される。これは、バイトコードが完全に実行されるまで続くことになる。

開示されているように、実施形態はコンパイルコールを遮り、コンパイル中にメモリポリシーに基づいてコールを許可するか、またはコールを不許可とする。メモリ内オブジェクトの意図しない制御不能な作成を阻止することによって、実施形態は、ＪＡＶＡ ＶＭを有するＧＲＯＯＶＹなどの、マルチユーザサーバ上で実行されるスクリプトをエンドユーザが入力することを可能にするシステムの安定性および性能を著しく向上させることができる。実施形態はＪＡＶＡ ＶＭへの変更に依存しないため、現在実現されているＪＡＶＡ ＶＭで用いることができる。

いくつかの実施形態が本明細書に具体的に例示され、かつ／または説明される。しかしながら、開示した実施形態の変更および変形例は、発明の精神および意図される範囲から逸脱することなく、上記の教示によって添付の請求項の範囲内に包含されることが認識されるであろう。

Claims (21)

1. 命令が格納されたコンピュータ読取可能媒体であって、前記命令は、プロセッサによって実行されると、前記プロセッサにメモリ管理ポリシーを実行時に実現させ、前記実現は、
   ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取ることと、
   前記構文ツリー内の複数のコールを識別することと、
   複数のメモリ変更済みコールを作成するために、前記複数のコールの各々を対応するメモリ変更済みコールにより変更することとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更することは、前記ソフトウェアコードのコンパイル中に生じ、さらに、
   前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成することを含む、コンピュータ読取可能媒体。
2. 前記複数のメモリ変更済みコールをコンパイルすることは、
   メモリ変更済みコールを実行することと、
   前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
   前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項１に記載のコンピュータ読取可能媒体。
3. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項２に記載のコンピュータ読取可能媒体。
4. 前記変更することは、コンパイルされていないソフトウェアコードに１つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項１に記載のコンピュータ読取可能媒体。
5. 前記コンパイルされていないコードは、ＧＲＯＯＶＹ言語として書込まれる、請求項１に記載のコンピュータ読取可能媒体。
6. 前記バイトコードは、ＪＡＶＡ仮想マシンによってマシンコードに変換される、請求項１に記載のコンピュータ読取可能媒体。
7. 前記メモリポリシーは、ＪＡＶＡメモリ制約に基づく、請求項２に記載のコンピュータ読取可能媒体。
8. 前記ソフトウェアコードは、リモートの相手から受取られる、請求項１に記載のコンピュータ読取可能媒体。
9. メモリ管理ポリシーを実行時に実現する方法であって、当該方法は、
   ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取ることと、
   前記構文ツリー内の複数のコールを識別することと、
   複数のメモリ変更済みコールを作成するために、前記複数のコールの各々を対応するメモリ変更済みコールにより変更することとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更することは、前記ソフトウェアコードのコンパイル中に生じ、さらに、
   前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成することを含む、方法。
10. 前記複数のメモリ変更済みコールをコンパイルすることは、
    メモリ変更済みコールを実行することと、
    前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
    前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項９に記載の方法。
11. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項９に記載の方法。
12. 前記変更することは、コンパイルされていないソフトウェアコードに１つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項９に記載の方法。
13. 前記コンパイルされていないコードは、ＧＲＯＯＶＹ言語として書込まれる、請求項９に記載の方法。
14. 前記バイトコードは、ＪＡＶＡ仮想マシンによってマシンコードに変換される、請求項９に記載の方法。
15. 前記メモリポリシーは、ＪＡＶＡメモリ制約に基づく、請求項１０に記載の方法。
16. ソフトウェアコンパイラであって、
    プロセッサと、
    前記プロセッサに結合され、前記プロセッサによって実行されるとモジュールを生成する命令を格納するメモリ装置とを備え、前記モジュールは、
    ソフトウェアコードのコンパイルの開始に応答して構文ツリーを受取り、前記構文ツリー内の複数のコールを識別する識別モジュールと、
    複数のメモリ変更済みコールを作成するために前記複数のコールの各々を対応するメモリ変更済みコールにより変更する変更モジュールとを含み、各メモリ変更済みコールはメモリ管理クラスとリンクされ、前記変更は、前記ソフトウェアコードのコンパイル中に生じ、さらに、
    前記複数のコールの各々の変更に引続いて、前記複数のメモリ変更済みコールをコンパイルしてバイトコードを生成するコンパイラモジュールを含む、ソフトウェアコンパイラ。
17. 前記複数のメモリ変更済みコールをコンパイルすることは、
    メモリ変更済みコールを実行することと、
    前記メモリ変更済みコールがメモリポリシーを満たすかどうかを判定することと、
    前記メモリ変更済みコールがメモリポリシーを満たさない場合、メモリ例外を生成することとを含む、請求項１６に記載のソフトウェアコンパイラ。
18. 前記実現はさらに、前記メモリ変更済みコールがメモリポリシーを満たさない場合、前記バイトコードの生成を停止させることを含む、請求項１７に記載のソフトウェアコンパイラ。
19. 前記変更することは、コンパイルされていないソフトウェアコードに１つ以上のアノテーションを付加することを含み、前記アノテーションは、操作クラスが呼出されるべきであることを示す、請求項１６に記載のソフトウェアコンパイラ。
20. 前記コンパイルされていないコードは、ＧＲＯＯＶＹ言語として書込まれる、請求項１６に記載のソフトウェアコンパイラ。
21. 前記バイトコードは、ＪＡＶＡ仮想マシンによってマシンコードに変換される、請求項１６に記載のソフトウェアコンパイラ。

Images