JP5588072B2

JP5588072B2 - メモリ割り当て方法、プログラム、及びシステム

Info

Publication number: JP5588072B2
Application number: JP2013532484A
Authority: JP
Inventors: 洋堀井; トマス・アール・ギッセル
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-09-09
Filing date: 2012-07-06
Publication date: 2014-09-10
Anticipated expiration: 2032-07-06
Also published as: EP2755129A1; WO2013035420A1; EP2755129A4; EP2755129B8; EP2755129B1; CN103782273A; US20130067190A1; JPWO2013035420A1

Description

この発明は、コンピュータにおけるメモリ割り当て技法に関し、より詳しくは、Java(R)などの処理系から、他の処理系によって管理するメモリ領域に対するメモリ割り当てを行う技法に関するものである。

従来より、様々なプラットフォームに対する適合性などの理由で、Java(R)がシステム構築のための処理系として使用されている。

一方で近年、大規模な分散処理システムで、キー・バリュー・ストア（ＫＶＳ）技術が採用されてきている。ＫＶＳ技術は、キーとバリューの組み合わせをハッシュを用いた連想配列（ハッシュ・マップ、HashMap）として多数保存する。このようなデータ構造をJava(R)で普通に実装すると、図１に示すように、ＫＶＳに保存された値が、複数のエントリ(Entry)をもつHashMap１０４として、ＫＶＳを実装するサーバ・システムのJava(R)のヒープ１０２に格納される。

また、サーバ・システムがクライアント・システムからリクエストを受け取ると、ByteBufferオブジェクト１０６がヒープ１０２に生成される。そのため、各HashMapに格納されるデータの型は、図1で示されるようなByteBufferオブジェクトの実データであるバイト配列（byte[]）、もしくは、ByteBufferそのものとなる。

しかし、このようにヒープ１０２上に多くのオブジェクトを配置すると、ヒープの空きが少なくなって、ガベージ・コレクションが頻繁に生じてしまう。ヒープ上のオブジェクトの数が増加すると、ガベージ・コレクションのオーバーヘッドも増加するため、必然的に、KVSを稼動するJVMでのガベージ・コレクションのオーバーヘッドは高くなる。

この問題の解決策として、図２に示すように、オブジェクトの実体は、Java(R)の管理外のメモリ領域（オフ・ヒープ２０２）上に置き、これらに対するアンカーのポインタとしてのオフ・ヒープ・マップ(OffHeapMap)２０４をヒープ１０２上に配置する仕組みが採る方法が有効である。この仕組みでは、サーバ・システムがクライアント・システムからリクエストを受け取るとき生成されるByteBuffer２０６の実体オブジェクトも、オフ・ヒープ２０２上に配置される。このようにオブジェクトの実体をオフ・ヒープ２０２上に置くことによって、ヒープ１０２のメモリ消費量、オブジェクト数を低下させることができ、ガベージ・コレクションのオーバーヘッドも低くすることが可能である。

Java(R)が、オフ・ヒープ２０２上にあるオブジェクトを標準APIを用いて取り扱うには、JNI(Java(R) Native Interface)という仕組みが使用される。JNIについては例えば、Rob Gordon, "Essential JNI: Java Native Interface", 1998, Prentice Hallなどを参照されたい。

さて、より具体的に、オフ・ヒープ２０２にある、予め割り当てられたメモリ・ブロック３０２を指し示すByteBufferを生成するには、JNIEnv->NewDirectByteBuffer(address,size)を呼び出す。ここで、addressは、オフ・ヒープ上のメモリ・ブロックの絶対アドレスであり、sizeは、そのメモリ・ブロックのサイズである。なお、Java(R)のByteBufferについては、Ron Hitchens, "Java Nio", 2002, O'Reillyなどを参照されたい。

JNIEnv->NewDirectByteBuffer(address,size)を呼び出すことによって、オフ・ヒープ２０２にある、予め割り当てられたアドレスのメモリ・ブロック３０２を指し示すByteBufferを生成することは可能であるが、実際上、その処理のオーバーヘッドが非常に大きいという問題がある。

すなわち、JNIEnv->NewDirectByteBuffer(address,size)は、具体的には次のようなステップからなる。
(1) Java(R)から、要求されるアドレス(address)とサイズ(size)で、JNIを実装するライブラリの処理系を呼び出す(Java(R)の処理系が実行する）。
(2) JNIEnv->NewDirectByteBuffer(address,size)を実行する(JNIを実装するライブラリ（C、C++）の処理系が実行する）。
(3) ByteBufferを生成するためのいくつかのJava(R)オブジェクトを生成し、その初期化を行うJava(R)の処理系を呼び出す。(JNIを実装するライブラリの処理系が実行する）
(4) 生成されたByteBufferをJNIを実装するライブラリの処理系に返す(Java(R)の処理系が実行する）。
(5) 返されたByteBufferをJava（R）の処理系に返す(JNIを実装するライブラリの処理系が実行する）。
(6) ByteBufferが利用可能になる。(Java(R)の処理系が実行する）
この個々のステップのオーバーヘッドが大きいので、全体のオーバーヘッドが非常に大きくなる。

従来のシステムでは、このオーバーヘッドが大きいJNIEnv->NewDirectByteBuffer(address,size)という処理を、例えばサーバ・システムがクライアント・システムからリクエストを受け取ってByteBufferを生成する必要がある度に実行する必要があるので、全体のパフォーマンスが低下してしまうという問題が生じる。

Rob Gordon, "Essential JNI: Java Native Interface", 1998, Prentice Hall Ron Hitchens, "Java Nio", 2002, O'Reilly

この発明の目的は、Java(R)などの処理系において、オフ・ヒープにアクセスするためのバッファを、JNIなどの所定のインターフェースで生成する際のオーバーヘッドを軽減することにある。

本発明によれば、上記課題は、この発明で特にファントムByteBufferと呼ぶ、仕様で許される範囲の大きいサイズのByteBufferを、１つまたは複数生成しておくことにより、解決される。

好適な実施例では、これらのファントムByteBufferの生成にはやはり、JNIEnv->NewDirectByteBuffer(address,size)が呼ばれ、その処理自体は上述のオーバーベッドがかかる。その際、ファントムByteBufferのアドレスとサイズで指定される範囲は、想定されるオフ・ヒープのメモリ・ブロックのアドレスの範囲をカバーするように設定される。但し、所定のJava(R) nioの仕様によれば、ByteBufferのサイズには、2GBという上限があるので、単一のファントムByteBufferでは想定されるオフ・ヒープのメモリ・ブロックのアドレスの範囲をカバーしきれない可能性がある。

そこで好適には、ファントムByteBufferは、想定されるオフ・ヒープのメモリ・ブロックのアドレスの範囲を広くカバーするように、アドレスをずらせて複数とるようにする。

このように、想定されるオフ・ヒープのメモリ・ブロックのアドレスの範囲を広くカバーするように、複数のファントムByteBufferが確保された状態で、システムから、アドレスとサイズを以ってByteBufferを作成する要求が送られてくると、ファントムByteBufferを生成しておいたプログラムは、そのアドレスとサイズで指定される範囲を含むファントムByteBufferに対して、ByteBufferに備わっているメソッドである、position()、limit()及びslice()を呼び出す。すなわち、position()の引数に要求されたアドレスを設定して実行し、limit()の引数に要求されたサイズを設定して実行し、slice()を実行することで、要求されたアドレスとサイズのByteBufferが切り出される。こうして切り出されたByteBufferを、指定されたオフ・ヒープのメモリ・ブロックに対するバッファとして使用することができる。さらにシステムから、アドレスとサイズで指定される範囲を以ってByteBufferを作成する要求が送られてくると、同様のことを繰り返す。

すなわち、一旦ファントムByteBufferを作成しておくことで、その後のシステムからの要求に対して、相対的にオーバーベッドの小さいByteBufferのメソッドを使ってスライスするだけで、要求されたByteBufferを作成することができる。

なお、システムから要求されたアドレスとサイズで指定される範囲を含むファントムByteBufferが見つからない場合は、そのアドレスとサイズで指定される範囲を含むファントムByteBufferを所定のオーバーヘッドで生成する処理が必要になるが、予め慎重に予測してファントムByteBufferを生成しておくことで、その必要性や頻度はかなり小さいと想定してよい。
また、用意するファントムByteBufferの数が多い際、各ByteBufferの生成の際に、指定される範囲を含むファントムByteBufferを特定するのにオーバーヘッドが高くなる場合がある。しかし、特定のファントムByteBufferに、要求されるアドレス、サイズで指定される範囲を含まないことが頻繁にある場合、そのファントムByteBufferを破棄することで、そのオーバーヘッドを軽減させることが可能である。

この発明によれば、Java(R)などの処理系において、予めファントムByteBufferを生成しておいて要求に応じてスライスすることによって、オフ・ヒープにアクセスするためのバッファを、JNIなどの所定のインターフェースで生成する際のオーバーヘッドを軽減することができる。

オン・ヒープ・マップの例を示す図である。オフ・ヒープ・マップの例を示す図である。ヒープ上のByteBufferと、オフ・ヒープ上のメモリ・ブロックの対応を示す図である。本発明を実施するためのハードウェアの一例のブロック図である。ソフトウェア構成のレイヤを示す図である。本発明の処理のフローチャートを示す図である。本発明の処理のフローチャートを示す図である。ヒープ上のファントムByteBufferと、オフ・ヒープ上のメモリ・ブロックの対応を示す図である。

以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。

図４を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図４において、システム・バス４０２には、ＣＰＵ４０４と、主記憶（ＲＡＭ）４０６と、ハードディスク・ドライブ（ＨＤＤ）４０８と、キーボード４１０と、マウス４１２と、ディスプレイ４１４が接続されている。ＣＰＵ４０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium(商標)4、インテル社のCore(商標) 2 DUO、AMD社のAthlon(商標)などを使用することができる。主記憶４０６は、好適には、４ＧＢ以上の容量、より好ましくは、８ＧＢ以上の容量をもつものである。

ハードディスク・ドライブ４０８には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Linux（商標）、マイクロソフト社のWindows(商標) 7、Windows XP(商標)、Windows(商標)2003サーバ、アップルコンピュータのMac OS(商標)などの、ＣＰＵ４０４に適合する任意のものでよい。

ハードディスク・ドライブ４０８にはまた、Apacheなどの、Ｗｅｂサーバとしてシステムを動作させるためのプログラムが保存され、システムの起動時に、主記憶４０６にロードされる。

ハードディスク・ドライブ４０８にはさらに、Java(R)仮想マシン（VM）を実現するためのJava(R) Runtime Environmentプログラムが保存され、システムの起動時に、主記憶４０６にロードされる。

ハードディスク・ドライブ４０８はさらに、バイトコードのアプリケーション・プログラムをオペレーティング・システム・ネイティブなコードに変換して実行させるＪＩＴコンパイラを含んでいてもよい。

ハードディスク・ドライブ４０８にはさらに、好適にはＣまたはＣ＋＋で書いてコンパイルされたバイナリのプログラムである、JNIによって呼び出されるライブラリが格納されている。

キーボード４１０及びマウス４１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ４１４に表示されたアイコン、タスクバー、テキストボックスなどのグラフィック・オブジェクトを操作するために使用される。

ディスプレイ４１４は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。ディスプレイ４１４は例えば、本発明を実装するプログラムを起動する画面を示すために使用される。

通信インターフェース４１６は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース４１６は、クライアント・コンピュータ（図示しない）からApacheが提供する機能により、ＴＣＰ／ＩＰなどの通信プロトコルに従い、処理リクエストを受け取り、あるいは処理結果を、クライアント・コンピュータ（図示しない）に返す。

図５は、プログラムまたはプロセスの階層を示す図である。図４に示すハードウェアの上で、オペレーティング・システム（ＯＳ）５０２が動作し、ＯＳ５０２上ではJava(R)仮想マシン（ＪＶＭ）５０４が動作し、ＪＶＭ５０４上では、アプリケーション・プログラム５０６が動作する。アプリケーション・プログラム５０６は、ソースコードをjavacなどでコンパイルされたバイトコードの形式でハードディスク・ドライブ４０８に保存されている。ＪＶＭ５０４は、JNIのインターフェース及びそのライブラリを含み、本発明のアプリケーション・プログラム５０６は、JNIのインターフェースを利用する。

次に、図６及び図７のフローチャートを参照して、アプリケーション・プログラム５０６が実行する処理について説明する。

図６のフローチャートは、好適にはアプリケーション・プログラム５０６の起動時に、アプリケーション・プログラム５０６が実行する処理に関する。アプリケーション・プログラム５０６は、ステップ６０２で、１つまたは複数のファントムByteBufferを生成する。ファントム(phantom)ByteBufferとは、本発明では特に、ＪＶＭにアクセスが許可されていない領域を含んでいてもよいメモリ空間を指し示すByteBufferを意味するものとする。ここでaddressは、オフ・ヒープのメモリ上でメモリ・ブロックが割り当てられるアドレスの範囲をカバーするように選ばれる。sizeは、好適には、java.nioの仕様の範囲で設定可能な最大値である2GBに設定される。ここで、ファントムByteBufferを生成する処理は、後述する図７のフローチャートで、ステップ７１２〜７２０で示す処理と同一である。

１つのファントムByteBufferの指し示すオフ・ヒープのメモリの範囲が2GBという制限があるので、もしアプリケーション・プログラム５０６が想定するオフ・ヒープのメモリの範囲が2GBより大きいと、単一のファントムByteBufferだけでは、アプリケーション・プログラム５０６が想定するオフ・ヒープのメモリの範囲をカバーしきれない。その場合は、可能な限りアプリケーション・プログラム５０６が想定するオフ・ヒープのメモリの範囲全体をカバーするように、アドレスの異なる複数のファントムByteBufferが生成される。

ステップ６０４で、アプリケーション・プログラム５０６は、生成されたファントムByteBufferのアドレスとサイズの値を、好適にはヒープの所定の領域に、例えばハッシュ・テーブルなどのテーブル・データとして登録する。

図７のフローチャートは、アプリケーション・プログラム５０６が、システムからのリクエストに応じて、ByteBufferを生成する処理に関する。

ステップ７０２は、アプリケーション・プログラム５０６が、システムから、アドレスとサイズを指定してByteBufferを生成するリクエストを受け取ったとき開始される。

すると、アプリケーション・プログラム５０６は、ステップ７０４で、図６のステップ６０４で登録した情報にアクセスして、指定されたアドレスとサイズの示す範囲を含むファントムByteBufferを探す。

ステップ７０６では、アプリケーション・プログラム５０６は、ステップ７０４での条件を満たすファントムByteBufferが見つかったかどうかを判断し、もしそうなら、ステップ７０８で、見つかったファントムByteBufferに対して、指定されたアドレスとサイズでスライスを行う。このために、ByteBufferに備わっているメソッドである、position()、limit()及びslice()を使用する。より具体的には、position()の引数に要求されたアドレスを設定して実行し、limit()の引数に要求されたサイズを設定して実行し、slice()を実行することで、要求されたアドレスとサイズのByteBufferが切り出される。こうして、ステップ７１０で、切り出されたByteBufferを、指定されたオフ・ヒープのメモリ・ブロックに対するバッファとして使用することができる。こうして、ByteBufferを生成する処理が終わる。

ステップ７０６に戻って、ステップ７０４での条件を満たすファントムByteBufferが見つからなかったならば、アプリケーション・プログラム５０６は、指定されたアドレスから始まる範囲のファントムByteBufferを生成する。この処理をより詳細に説明すると、アプリケーション・プログラム５０６は、ステップ７１２で、Java(R)からJNIを呼ぶ。

次にアプリケーション・プログラム５０６は、ステップ７１４で、指定されたアドレスと最大サイズ(2GB)でJNIEnv->NewDirectByteBuffer(address,size)を呼ぶ。

次にアプリケーション・プログラム５０６は、ステップ７１６で、ByteBufferのためのいくつかのオブジェクトを生成する。

ステップ７１８では、生成したByteBufferがJava(R)に返される。

次にアプリケーション・プログラム５０６は、ステップ７２０で、生成したByteBufferをファントムByteBufferとして登録する。

こうして処理は、ステップ７０４に戻る。すると新たにファントムByteBufferが登録されたので、ステップ７０４では該当するファントムByteBufferが見つかり、ステップ７０６での判断が肯定的になって、ステップ７０８で、既述のように、スライスによりByteBufferが生成されることになる。

ステップ７０６でファントムByteBufferが見つからなかったと判断された場合に行われるステップ７１２〜７２０は、オーバーヘッドが大きいが、予め想定した範囲のメモリのアドレスをカバーするようにファントムByteBufferを用意しておくことにより、ほとんどの場合に該当するファントムByteBufferが見つかるので、ステップ７０６での判断は肯定的になってステップ７０８に進むので、オーバーヘッドの問題はほとんど生じない。

図８は、ファントムByteBufferから、実ByteBufferがスライスされた切り出される様子を図式的に示す図である。図８において、ファントムByteBuffer８０２は、図６のステップ６０２で予め生成される。

その後、図７のステップ７０２に示すように、システムからByteBufferを生成する要求が来ると、実（すなわちファントムでない）ByteBuffer８０４が、ファントムByteBufferをスライスすることによってステップ７０８で生成されて、オフ・ヒープのメモリ・ブロック８０８を指し示す。

その後、システムからByteBufferを生成する別の要求が来ると、実ByteBuffer８０６が、ファントムByteBufferをスライスすることによってステップ７０８で生成されて、オフ・ヒープのメモリ・ブロック８１０を指し示す。

このように、オーバーヘッドをかけて一旦ファントムByteBufferを生成しておくと、その後はファントムByteBufferをスライスするだけで、所望の実ByteBufferを何個でも生成することができる。ByteBufferをスライスする処理は、JNIとは異なり、Java(R)内だけで完結する相対的にオーバーヘッドの小さい処理である。

以上、Java(R)からJNIを経由してオフ・ヒープ上のメモリ・ブロックを指し示すバッファを作成する例において、本発明の実施例を説明したが、この発明は、他システムへのネイティブ・インターフェースをもつ処理系であるなら、特定のハードウェア及びオペレーティング・システム、処理系あるいはアプリケーション・プログラムに限定されないことに留意されたい。

４０４・・・ＣＰＵ
４０６・・・主記憶
４０８・・・ハードディスク・ドライブ
５０２・・・ＯＳ
５０４・・・ＪＶＭ
５０６・・・アプリケーション・プログラム
８０２・・・ファントムByteBuffer
８０４・・・実ByteBuffer
８０６・・・実ByteBuffer

Claims

絶対アドレスで、指定したメモリ空間へのアクセスを行うバッファのクラスをもち、さらに、該特別なクラスによって指定されたメモリ空間の一部をスライスして該クラスを生成する機能をもつ言語処理系上でプログラムを実行するシステムにおいて、前記指定したメモリ空間へのアクセスを行うクラスのバッファをコンピュータの処理によって生成する方法であって、
前記コンピュータの処理によって、前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成するステップと、
利用が許可されたメモリ空間とサイズが指定されたことに応答して、前記コンピュータの処理によって、前記生成されたクラスの前記バッファをスライスすることによって、該利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成するステップを有する、
方法。
前記言語処理系にアクセスが許可されていない領域を含んでいてもよいメモリ空間に対して前記クラスのバッファを複数生成してアドレスとサイズを記録しておくステップをさらに有する、請求項１に記載の方法。
前記利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成するステップが、前記複数生成されてアドレスを記録されたクラスの前記バッファから、指定されたアドレスとサイズの示す範囲を含むバッファを見出してスライスする処理を含む、請求項２に記載の方法。
前記アドレスを含むクラスの所定のバッファを見出してスライスする処理が、前記アドレスを含む所定のバッファのクラスを見つけられないことに応答して、前記言語処理系にアクセスが許可されていないメモリ空間に対するアドレスを含む、クラスの追加のバッファ生成する処理を含む、請求項３に記載の方法。
前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成するステップが、許容される最大のサイズでバッファを生成する、請求項１に記載の方法。
前記言語処理系がJava(R)であり、前記バッファのクラスがByteBufferであり、前記バッファのクラスを生成する処理がJNIインターフェースを呼び出して実行され、前記バッファのクラスを切り出す処理がposition()で開始点を指定し、limit()でサイズを指定した後に、slice()メソッドにより実行される、請求項１に記載の方法。
絶対アドレスで、指定したメモリ空間へのアクセスを行うバッファのクラスをもち、さらに、該特別なクラスによって指定されたメモリ空間の一部をスライスして該クラスを生成する機能をもつ言語処理系上でプログラムを実行するシステムにおいて、前記指定したメモリ空間へのアクセスを行うクラスのバッファをコンピュータの処理によって生成するプログラムであって、
前記コンピュータに、
前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成するステップと、
利用が許可されたメモリ空間とサイズが指定されたことに応答して、前記生成されたクラスの前記バッファをスライスすることによって、該利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成するステップを実行させる、
プログラム。
前記言語処理系にアクセスが許可されていない領域を含んでいてもよいメモリ空間に対して前記クラスのバッファを複数生成してアドレスとサイズを記録しておくステップをさらに有する、請求項７に記載のプログラム。
前記利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成するステップが、前記複数生成されてアドレスを記録されたクラスの前記バッファから、指定されたアドレスとサイズの示す範囲を含むバッファを見出してスライスする処理を含む、請求項８に記載のプログラム。
前記アドレスを含むクラスの所定のバッファを見出してスライスする処理が、前記アド
レスを含む所定のバッファのクラスを見つけられないことに応答して、前記言語処理系にアクセスが許可されていないメモリ空間に対するアドレスを含む、クラスの追加のバッファ生成する処理を含む、請求項９に記載のプログラム。
前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成するステップが、許容される最大のサイズでバッファを生成する、請求項７に記載のプログラム。
前記言語処理系がJava(R)であり、前記バッファのクラスがByteBufferであり、前記バッファのクラスを生成する処理がJNIインターフェースを呼び出して実行され、前記バッファのクラスを切り出す処理がposition()で開始点を指定し、limit()でサイズを指定した後に、slice()メソッドにより実行される、請求項７に記載のプログラム。
絶対アドレスで、指定したメモリ空間へのアクセスを行うバッファのクラスをもち、さらに、該特別なクラスによって指定されたメモリ空間の一部をスライスして該クラスを生成する機能をもつ言語処理系上でプログラムを実行するシステムにおいて、
前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成する手段と、
利用が許可されたメモリ空間とサイズが指定されたことに応答して、前記生成されたクラスの前記バッファをスライスすることによって、該利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成する手段を有する、
システム。
前記言語処理系にアクセスが許可されていない領域を含んでいてもよいメモリ空間に対して前記クラスのバッファを複数生成してアドレスとサイズを記録しておく手段をさらに有する、請求項１３に記載のシステム。
前記利用が許可されたメモリ空間にアクセス可能なクラスのバッファを生成する手段が、前記複数生成されてアドレスを記録されたクラスの前記バッファから、指定されたアドレスとサイズの示す範囲を含むバッファを見出してスライスする処理を実行する、請求項１４に記載のシステム。
前記アドレスを含むクラスの所定のバッファを見出してスライスする処理が、前記アドレスを含む所定のバッファのクラスを見つけられないことに応答して、前記言語処理系にアクセスが許可されていないメモリ空間に対するアドレスを含む、クラスの追加のバッファ生成する処理を実行する、請求項１５に記載のシステム。
前記言語処理系にアクセスが許可されていないメモリ空間を含んでいてもよい、前記クラスのバッファを生成する手段が、許容される最大のサイズでバッファを生成する、請求項１３に記載のシステム。
前記言語処理系がJava(R)であり、前記バッファのクラスがByteBufferであり、前記バッファのクラスを生成する処理がJNIインターフェースを呼び出して実行され、前記バッファのクラスを切り出す処理がposition()で開始点を指定し、limit()でサイズを指定した後に、slice()メソッドにより実行される、請求項１３に記載のシステム。