(57)【要約】【課題】ネイティブプログラムとの間で効率の良いデータ連携を行うこと。【解決手段】Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、データ型によって、Ｊａｖａ（Ｒ）オブジェクトを第１のタイプのＪａｖａ（Ｒ）オブジェクトと、第２のタイプのＪａｖａ（Ｒ）オブジェクトに分類し、第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第１のメモリ領域に空きがない場合にはこの第１のメモリ領域に対して第１のコンパクション処理を実行し、第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第２のメモリ領域に空きがない場合にはこの第２のメモリ領域に対して、第１のコンパクション処理とは異なる第２のコンパクション処理を実行し、第１のコンパクション処理により空きが発生した第１のメモリ領域に第１のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするとともに、第２のコンパクション処理により空きが発生した第２のメモリ領域に第２のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートする。【選択図】      図４
2006039878.tif 000002
【特許請求の範囲】
【請求項１】
Ｊａｖａ（Ｒ）実行環境におけるメモリ管理方法であって、
Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、データ型によって、前記Ｊａｖａ（Ｒ）オブジェクトを第１のタイプのＪａｖａ（Ｒ）オブジェクトと、第２のタイプのＪａｖａ（Ｒ）オブジェクトに分類するオブジェクト分類ステップと、
前記第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第１のメモリ領域に空きがない場合にはこの第１のメモリ領域に対して第１のコンパクション処理を実行し、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第２のメモリ領域に空きがない場合にはこの第２のメモリ領域に対して、前記第１のコンパクション処理とは異なる第２のコンパクション処理を実行するコンパクション実行ステップと、
前記第１のコンパクション処理により空きが発生した前記第１のメモリ領域に前記第１のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするとともに、前記第２のコンパクション処理により空きが発生した前記第２のメモリ領域に前記第２のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするオブジェクトアロケーションステップと、
を具備することを特徴とするメモリ管理方法。
【請求項２】
前記第２のメモリ領域には、所定のマークが付与されたＪａｖａ（Ｒ）オブジェクトがアロケートされており、前記第２のコンパクション処理では、前記マークが付与されたＪａｖａ（Ｒ）オブジェクトに対するコンパクション処理を行わないことを特徴とする請求項１に記載のメモリ管理方法。
【請求項３】
ネイティブプログラムから利用されるＪａｖａ（Ｒ）オブジェクトに所定のマークを付与することを特徴とする請求項２に記載のメモリ管理方法。
【請求項４】
前記第２のタイプのＪａｖａ（Ｒ）オブジェクトは、ｂｙｔｅの１次元配列のデータ型をもつことを特徴とする請求項１から３のいずれか１項に記載のメモリ管理方法。
【請求項５】
前記ｂｙｔｅの１次元配列をもつＪａｖａ（Ｒ）オブジェクトは、音声データ、画像データあるいは通信データであることを特徴とする請求項１から４のいずれか１項に記載のメモリ管理方法。
【請求項６】
ネイティブプログラムとの間でデータの連携を行うＪａｖａ（Ｒ）実行環境におけるメモリ管理プログラムであって、
処理手段に、
Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、データ型によって、前記Ｊａｖａ（Ｒ）オブジェクトを第１のタイプのＪａｖａ（Ｒ）オブジェクトと、第２のタイプのＪａｖａ（Ｒ）オブジェクトに分類するオブジェクト分類処理と、
前記第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第１のメモリ領域に空きがない場合にはこの第１のメモリ領域に対して第１のコンパクション処理を実行し、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第２のメモリ領域に空きがない場合にはこの第２のメモリ領域に対して、前記第１のコンパクション処理とは異なる第２のコンパクション処理を実行するコンパクション処理と、
前記第１のコンパクション処理により空きが発生した前記第１のメモリ領域に前記第１のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするとともに、前記第２のコンパクション処理により空きが発生した前記第２のメモリ領域に前記第２のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするオブジェクトアロケーション処理と、
を実行させることを特徴とするメモリ管理プログラム。
【請求項７】
前記第２のメモリ領域には、所定のマークが付与されたＪａｖａ（Ｒ）オブジェクトがアロケートされており、前記第２のコンパクション処理では、前記マークが付与されたＪａｖａ（Ｒ）オブジェクトに対するコンパクション処理を行わないことを特徴とする請求項６に記載のメモリ管理プログラム。
【請求項８】
ネイティブプログラムから利用されるＪａｖａ（Ｒ）オブジェクトに所定のマークを付与することを特徴とする請求項７に記載のメモリ管理プログラム。
【請求項９】
前記第２のタイプのＪａｖａ（Ｒ）オブジェクトは、ｂｙｔｅの１次元配列のデータ型をもつことを特徴とする請求項６から８のいずれか１項に記載のメモリ管理プログラム。
【請求項１０】
前記ｂｙｔｅの１次元配列をもつＪａｖａ（Ｒ）オブジェクトは、音声データ、画像データあるいは通信データであることを特徴とする請求項６から９のいずれか１項に記載のメモリ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｊａｖａ（Ｒ）実行環境におけるメモリ管理方法及びメモリ管理プログラムに関するものである。
【背景技術】
【０００２】
Sun Microsystems社によって開発されたＪａｖａ（Ｒ）技術は、特にインターネットの世界を中心に発展し、その後、サーバサイドＪａｖａ（Ｒ）やアプリケーションソフトウェアの開発に利用され、最近では、携帯電話にも利用されている。携帯電話で利用されるＪａｖａ（Ｒ）プログラムでは、音声、静止画、動画などのマルチメディアデータを取り扱うことが多い。特に昨今では、通信速度の高速化や表示画面の高精細化に伴ってこれらのマルチメディアデータのサイズは急激に増加する傾向にある。
【０００３】
このようなマルチメディアデータを再生したり加工する場合、Ｊａｖａ（Ｒ）実行環境から独立した外部のネイティブプログラムによってこの処理が行われるのが一般的である。したがってこの場合、Ｊａｖａ（Ｒ）実行環境とネイティブプログラムとの間のデータの連携動作が必要になる。ここでネイティブプログラムの例としては、音声や動画などの再生用プログラムとしてのデコーダ、記録用プログラムとしてのエンコーダさらには、通信用プロトコルスタックがある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
Ｊａｖａ（Ｒ）実行環境が備えるメモリ管理機構は、Ｊａｖａ（Ｒ）オブジェクトを効率良く扱えるように設計されており、使用されなくなったメモリを回収するためのガーベジコレクションの機能や、メモリのフラグメンテーションを防ぐためにコンパクションの機構を備えている。
【０００５】
しかし、このようなメモリ管理機構で管理されているＪａｖａ（Ｒ）オブジェクトの中には、他のＪａｖａ（Ｒ）オブジェクトと同様に管理することができないものが存在する場合がある。
【０００６】
例えば、Ｊａｖａ（Ｒ）実行環境とは非同期に動作するネイティブプログラムにより処理されるＪａｖａ（Ｒ）オブジェクトがある場合、処理の途中でメモリ管理機構によるコンパクションが行なわれると、コンパクションにより処理中のデータが移動してネイティブプログラムから読み出せなくなってしまうという問題が生じる。
【０００７】
このような問題に対処するために、Ｊａｖａ（Ｒ）プログラムが扱っているデータをネイティブプログラムにより処理する場合には、当該データを、Ｊａｖａ（Ｒ）プログラム用に割り当てられたヒープ領域とは別に確保したメモリ領域にコピーしてから、ネイティブプログラムによる処理を行う方法がある。
【０００８】
上記の方法では、さらに、ネイティブプログラムがデータを更新した後に、当該ネイティブプログラムからＪａｖａ（Ｒ）プログラムに処理を戻す場合には、データの整合性をとるために、ネイティブプログラムが更新したデータをヒープ領域にコピーして書き戻すことを行っている。
【０００９】
このように、Ｊａｖａ（Ｒ）プログラムが利用するヒープ領域と、ネイティブプログラムが利用する別のメモリ領域との間でデータをコピーする処理が発生すると、システムのメモリ容量が多量に消費されるとともに、コピーに要する時間だけ処理が遅延するという問題が発生する。特に、メモリサイズの大きい音声や動画のデータを扱う場合には、メモリ容量の消費はきわめて大きなものとなり、処理の遅延も顕著なものとなる。
【００１０】
本発明は、このような課題に着目してなされたものであり、その目的とするところは、Ｊａｖａ（Ｒ）実行環境で利用されるメモリ管理機構およびメモリ管理プログラムであって、特性の異なるデータであっても効率よく管理することができ、特にネイティブプログラムとの間で効率の良いデータの連携を行うことができるメモリ管理機構およびメモリ管理プログラムを提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するために、本発明者は研究を重ねた結果、ネイティブプログラムから利用される頻度がＪａｖａ（Ｒ）オブジェクトのデータ型によって相違すること、特にｂｙｔｅ［］のＪａｖａ（Ｒ）オブジェクトがネイティブプログラムから利用される頻度が高いことを見出した。
【００１２】
本発明は、上記知見に鑑みてなされたものであって、第１の発明にかかるメモリ管理方法は、Ｊａｖａ（Ｒ）実行環境におけるメモリ管理方法であって、Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、データ型によって、前記Ｊａｖａ（Ｒ）オブジェクトを前記第１のタイプのＪａｖａ（Ｒ）オブジェクトと、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトに分類するオブジェクト分類ステップと、前記第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第１のメモリ領域に空きがない場合にはこの第１のメモリ領域に対して第１のコンパクション処理を実行し、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第２のメモリ領域に空きがない場合にはこの第２のメモリ領域に対して、前記第１のコンパクション処理とは異なる第２のコンパクション処理を実行するコンパクション実行ステップと、前記第１のコンパクション処理により空きが発生した前記第１のメモリ領域に前記第１のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするとともに、前記第２のコンパクション処理により空きが発生した前記第２のメモリ領域に前記第２のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするオブジェクトアロケーションステップと、を具備する。
【００１３】
また、第２の発明は、第１の発明にかかるメモリ管理方法において、前記第２のメモリ領域には、所定のマークが付与されたＪａｖａ（Ｒ）オブジェクトがアロケートされており、前記第２のコンパクション処理では、前記マークが付与されたＪａｖａ（Ｒ）オブジェクトに対するコンパクション処理を行わない。
【００１４】
また、第３の発明は、第２の発明にかかるメモリ管理方法において、ネイティブプログラムから利用されるＪａｖａ（Ｒ）オブジェクトに所定のマークを付与する。
【００１５】
また、第４の発明は、第１から第３のいずれか１つの発明にかかるメモリ管理方法において、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトは、ｂｙｔｅの１次元配列のデータ型をもつ。
【００１６】
また、第５の発明は、第１から第４のいずれか１つの発明にかかるメモリ管理方法において、前記ｂｙｔｅの１次元配列をもつＪａｖａ（Ｒ）オブジェクトは、音声データ、画像データあるいは通信データである。
【００１７】
また、第６の発明にかかるメモリ管理プログラムは、ネイティブプログラムとの間でデータの連携を行うＪａｖａ（Ｒ）実行環境におけるメモリ管理プログラムであって、処理手段に、Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、前記ネイティブプログラムにより利用される頻度に応じて、前記Ｊａｖａ（Ｒ）オブジェクトを第１のタイプのＪａｖａ（Ｒ）オブジェクトと、第２のタイプのＪａｖａ（Ｒ）オブジェクトに分類するオブジェクト分類処理と、前記第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第１のメモリ領域に空きがない場合にはこの第１のメモリ領域に対して第１のコンパクション処理を実行し、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる第２のメモリ領域に空きがない場合にはこの第２のメモリ領域に対して、前記第１のコンパクション処理とは異なる第２のコンパクション処理を実行するコンパクション処理と、前記第１のコンパクション処理により空きが発生した前記第１のメモリ領域に前記第１のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするとともに、前記第２のコンパクション処理により空きが発生した前記第２のメモリ領域に前記第２のタイプのＪａｖａ（Ｒ）オブジェクトをアロケートするオブジェクトアロケーション処理と、を実行させる。
【００１８】
また、第７の発明は、第６の発明にかかるメモリ管理プログラムにおいて、前記第２のメモリ領域には、所定のマークが付与されたＪａｖａ（Ｒ）オブジェクトがアロケートされており、前記第２のコンパクション処理では、前記マークが付与されたＪａｖａ（Ｒ）オブジェクトに対するコンパクション処理を行わない。
【００１９】
また、第８の発明は、第７の発明にかかるメモリ管理プログラムにおいて、ネイティブプログラムから利用されるＪａｖａ（Ｒ）オブジェクトに所定のマークを付与する。
【００２０】
また、第９の発明は、第７または第８の発明にかかるメモリ管理プログラムにおいて、前記第２のタイプのＪａｖａ（Ｒ）オブジェクトは、ｂｙｔｅの１次元配列のデータ型をもつ。
【００２１】
また、第１０の発明は、第６から第９のいずれか１つの発明にかかるメモリ管理プログラムにおいて、前記ｂｙｔｅの１次元配列をもつＪａｖａ（Ｒ）オブジェクトは、音声データ、画像データあるいは通信データである。
【発明の効果】
【００２２】
本発明によれば、Ｊａｖａ（Ｒ）オブジェクトのデータ型に応じて、互いに異なるコンパクション処理が施されるメモリ領域を使い分けることができるので、オブジェクトのデータ型に応じて異なるコンパクション処理を適用することができ、これにより利用される形態や性質が異なるオブジェクトが存在しても、効率よくメモリ管理を行うことが可能である。
【００２３】
本発明は、特にネイティブプログラムによって利用される頻度が高いデータ型のＪａｖａ（Ｒ）オブジェクトとそれ以外のオブジェクトとで、互いに異なるコンパクション処理が施されるメモリ領域を使い分ける場合に適用することが好適である。この場合には、ネイティブプログラムによって利用されるＪａｖａ（Ｒ）オブジェクトについてはコンパクション処理を行わないようにすることで、コンパクション処理時のオブジェクト移動に対処するためのメモリ領域の確保やコピー動作が不要になり、Ｊａｖａ（Ｒ）プログラムとネイティブプログラムとのデータ連携を極めて効率良く行うことが可能になる。
【発明を実施するための最良の形態】
【００２４】
まず、本実施形態の概略を説明する。Ｊａｖａ（Ｒ）実行環境において、多くのＪａｖａ（Ｒ）オブジェクトはＪａｖａ（Ｒ）プログラムのみから利用されるものであり、ネイティブプログラムとの間でデータの連携を行う場合に、当該ネイティブプログラムにより利用されるＪａｖａ（Ｒ）オブジェクトはごく一部である。ここで、ネイティブプログラムで利用されるＪａｖａ（Ｒ）オブジェクトについてはコンパクション処理によるアドレスの移動に対処する必要があるものの、その他のＪａｖａ（Ｒ）オブジェクトについてはそのような対処を必要としない。したがって、それらを区別して管理することで効率の良いメモリ運用を実現することが可能である。
【００２５】
本発明者がＪａｖａ（Ｒ）と連携するネイティブプログラムを注意深く観察した結果、ネイティブプログラムによって利用されるＪａｖａ（Ｒ）オブジェクトは、殆どの場合にデータ型としてｂｙｔｅの１次元配列をもつことがわかった。ｂｙｔｅの１次元配列をもつＪａｖａ（Ｒ）オブジェクト（ｂｙｔｅ［］オブジェクト）の具体例としては、音声データや画像（動画を含む）データといったマルチメディアデータ、通信データなどが挙げられる。
【００２６】
そこで本実施形態では、通常のＪａｖａ（Ｒ）オブジェクトは第１のタイプのＪａｖａ（Ｒ）オブジェクト、ｂｙｔｅ［］オブジェクトは第２のタイプのＪａｖａ（Ｒ）オブジェクトとして分類し、第１のタイプのＪａｖａ（Ｒ）オブジェクトはヒープ領域内の第１の領域に格納し、第２のタイプのＪａｖａ（Ｒ）オブジェクトはヒープ領域内の第２の領域に格納するようにする。そして、第２の領域内のｂｙｔｅ［］オブジェクトのうち、ネイティブプログラムにより利用されるＪａｖａ（Ｒ）オブジェクトについては、ネイティブプログラムとのデータ連携の間コンパクション処理時の移動を禁止する所定のマークを付与する。ここでは移動させないＪａｖａ（Ｒ）オブジェクトについてはマークビットをＯＮ状態にセットすることによりロックする。ロックされたＪａｖａ（Ｒ）オブジェクトは後述のようにコンパクション処理の対象外となり移動されることはない。ネイティブプログラムとのデータ連携が終了した後は、マークビットがＯＦＦ状態とされて、ロックが解除される。
【００２７】
なお、コンパクション処理時の移動を許可するか禁止するかを区別する方法として、所定のマークをＪａｖａ（Ｒ）オブジェクトにそれぞれ付与するのでなく、Ｊａｖａ（Ｒ）オブジェクトごとに移動の許可あるいは禁止の情報を書き込んだ管理テーブルを用いるようにしても良い。
【００２８】
新たなＪａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したときに、アロケートするために十分なメモリ領域が存在しない場合には、使用されなくなったメモリを回収するためのガーベジコレクション処理や、細かく分断された使用中メモリ領域をまとめて連続したメモリ領域にするコンパクション処理を行うことになるが、この場合、第１のタイプのＪａｖａ（Ｒ）オブジェクトが格納されている第１の領域ではコンパクション処理によってすべてのオブジェクトが移動され、フラグメンテーションの発生が防止される。一方、第２のタイプのＪａｖａ（Ｒ）オブジェクトが格納された第２の領域に対するコンパクション処理ではこれとは異なるコンパクション処理が実行される。すなわち、ここでのコンパクション処理は、マークビットがＯＮ状態にセットされてロックされているオブジェクトについては移動させず、それ以外のオブジェクトのみを移動させることで行われる。
【００２９】
そして、上記コンパクション処理により空きが発生した第１のメモリ領域に第１のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされ、上記コンパクション処理により空きが発生した第２のメモリ領域に第２のタイプのＪａｖａ（Ｒ）オブジェクトがアロケートされる。
【００３０】
このように本実施形態においては、ネイティブプログラムにより利用される頻度の高いｂｙｔｅ［］オブジェクトは第２のメモリ領域に配置され、さらにネイティブプログラムにより実際に利用されている間は当該オブジェクトのマークビットがＯＮ状態にセットされる。そして、第２のメモリ領域に対するコンパクション処理は、マークビットがＯＮ状態のオブジェクトを移動させないので、ネイティブプログラムにより利用されているオブジェクトがコンパクション処理により移動されることはない。したがって、コンパクション処理によるオブジェクト移動に対応するために新たなメモリ領域をヒープ領域外に確保してコピーする動作が不要になり、これによってネイティブプログラムとのデータ連携を効率良く行うことが可能になる。この場合、ｂｙｔｅ［］オブジェクト以外のオブジェクトについては通常のコンパクション処理が行われるので、従来のＪａｖａ（Ｒ）実行環境におけるメモリ管理と同様のメモリ管理が可能である。
【００３１】
第２のメモリ領域に適用されるメモリ管理（特にコンパクション処理）はＪａｖａ（Ｒ）オブジェクトがロックされているか否かの判断を伴うためオーバーヘッドを伴うが、第１のメモリ領域には従来通りのメモリ管理が適用されるため、その影響は小さく抑えることができる。
【００３２】
また、ネイティブプログラムから利用されるＪａｖａ（Ｒ）オブジェクトは、特にマルチメディアデータであると容量が大きい場合が多く、このようなＪａｖａ（Ｒ）オブジェクトがＪａｖａ（Ｒ）実行環境の利用するヒープ領域全体に分散してロックされるとフラグメンテーションの発生が問題となる。しかし、本実施形態では、ネイティブから利用されるＪａｖａ（Ｒ）オブジェクトは主として第２のメモリ領域に配置されるので、フラグメンテーションが発生したとしてもその影響は第２のメモリ領域に限定されたものとすることができる。
【００３３】
なお、ｂｙｔｅ［］オブジェクト以外のオブジェクトをネイティブプログラムから利用する場合には、そのようなオブジェクトは第１のメモリ領域に配置されているため、従来と同様にヒープ領域外部にコピーする必要があるが、その頻度は極めて低いので問題はない。
【００３４】
また、通常のＪａｖａ（Ｒ）オブジェクトと、ネイティブプログラムと連携するＪａｖａ（Ｒ）オブジェクトとでは、サイズや生存期間の傾向が異なるので、ネイティブプログラムと連携する頻度が高いデータと低いデータとを分離して管理することでメモリ管理の効率も向上する。
【００３５】
さらに、Ｊａｖａ（Ｒ）言語仕様に対して新たな拡張を加えたわけではないので、Ｊａｖａ（Ｒ）実行環境側だけの修正で済み、既存のプログラムを修正する必要がない等、既存のプログラムとの親和性を維持することができる。
【００３６】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００３７】
図１は、本発明を実施するためのハードウェア構成の説明図であり、ここでは、本実施形態のＪａｖａ（Ｒ）実行環境を搭載した組み込み機器（例えば携帯電話）のハードウェア構成を示している。図１において、メモリ１１は種々のプログラムやデータを格納する部分である。入出力部１３はユーザインタフェースとなる部分であり、入力キー、マイク、スピーカなどで構成される。表示部１２は種々のメニューや動作状況等の情報を表示する部分である。ＣＰＵ１０は、装置各部の動作を制御する部分である。本実施形態で用いられるＪａｖａ（Ｒ）オブジェクト分類機能、メモリ領域コンパクション機能、Ｊａｖａ（Ｒ）オブジェクトアロケーション機能は、ＣＰＵ１０がメモリ１１に格納された各種のプログラムを読み出して実行したときに仮想的に構築されるようになっている。
【００３８】
図２は、本発明を実施するためのソフトウェア構成の説明図である。図２に示すように、プラットフォーム（ＯＳ及びハードウェア）２３上には、Ｊａｖａ（Ｒ）実行環境としてＶＭ（Virtual Machine）２４、クラスライブラリ２２、Ｊａｖａ（Ｒ）アプリケーション２０が搭載されている。ＶＭ２４は、Ｊａｖａ（Ｒ）バイトコードが格納されたクラスファイルをネイティブコードに変換しながら実行するプログラムである。
【００３９】
なお、ＶＭ２４は、Ｊａｖａ（Ｒ）ヒープ領域２５を有し、ここでは図３に示すように、通常のＪａｖａ（Ｒ）オブジェクトがアロケートされる第１の領域２５−１と、ｂｙｔｅ［］オブジェクトがアロケートされる第２の領域２５−２とが設けられている。さらに、Ｊａｖａ（Ｒ）実行環境とデータの連携（リード・ライト）を行うネイティブプログラムアプリケーション１（２６）、２（２７）が搭載されている。
【００４０】
図４は、Ｊａｖａ（Ｒ）オブジェクトを本実施形態の方法によりアロケートする手順を示すフローチャートである。
【００４１】
Ｊａｖａ（Ｒ）オブジェクトをヒープ領域にアロケートする要求が発生したとき、ＣＰＵ１０は、当該Ｊａｖａ（Ｒ）オブジェクトのデータ型がｂｙｔｅ［］であるか否かを判断し（ステップＳ１）、ＮＯの場合、すなわち通常のＪａｖａ（Ｒ）オブジェクトである場合にはＪａｖａ（Ｒ）ヒープ領域２５の第１の領域２５−１に空きがあるか否かを判断する（ステップＳ２）。ここでの判断がＹＥＳの場合には第１の領域２５−１に当該Ｊａｖａ（Ｒ）オブジェクトをアロケートし（ステップＳ５）、その後、終了する。
【００４２】
また、ステップＳ２の判断がＮＯの場合には、第１、第２の領域２５−１，２５−２に対してガーベジコレクションを実行して使用されていない領域を開放するとともに、第１の領域２５−１内の使用中のＪａｖａ（Ｒ）オブジェクトを移動させるコンパクション処理を実行する（ステップＳ３）。次に、上記のガーベジコレクションとコンパクション処理により第１の領域２５−１に空きが生成されたか否かを判断し（ステップＳ４）、ＹＥＳの場合には第１の領域２５−１にＪａｖａ（Ｒ）オブジェクトをアロケートし（ステップＳ５）、その後、終了する。一方、ステップＳ４の判断がＮＯの場合には空き領域なしのエラーメッセージを表示して（ステップＳ６）、終了する。
【００４３】
一方、ステップＳ１の判断がＹＥＳの場合には、Ｊａｖａ（Ｒ）ヒープ領域２５の第２の領域２５−２に空きがあるか否かを判断する（ステップＳ７）。ここでの判断がＹＥＳの場合には第２の領域２５−２に当該Ｊａｖａ（Ｒ）オブジェクトをアロケートし（ステップＳ１０）、その後、終了する。
【００４４】
また、ステップＳ７の判断がＮＯの場合には、第１、第２の領域２５−１，２５−２に対してガーベジコレクションを実行して使用されていない領域を開放するとともに、第２の領域２５−２内の、ロックされていない使用中のＪａｖａ（Ｒ）オブジェクトのみを移動させるコンパクション処理を実行する（ステップＳ８）。次に、上記のガーベジコレクションとコンパクション処理により第２の領域２５−２に空きが生成されたか否かを判断し（ステップＳ９）、ＹＥＳの場合には第２の領域２５−２にＪａｖａ（Ｒ）オブジェクトをアロケートし（ステップＳ１０）、その後、終了する。一方、ステップＳ９の判断がＮＯの場合には空き領域なしのエラーメッセージを表示して（ステップＳ６）、終了する。
【００４５】
なお、本発明は、上記実施の形態に限らず種々変形が可能である。例えば、Ｊａｖａ（Ｒ）の後継となる言語系が新たに提案された場合であっても、当該言語系が実行環境によるガーベジコレクションやコンパクションといったメモリ管理を想定したものであれば、本発明のメモリ管理方法およびメモリ管理プログラムを上記実施の形態と同様に適用することが可能である。また、ガーベジコレクションやコンパクションの方法にも制限はなく、適用可能な方法を適宜使用することができる。また、そのガーベジコレクションやコンパクションを行うタイミングも上記実施の形態に限られるものではなく、Ｊａｖａ（Ｒ）オブジェクトをアロケートする要求発生のタイミングとは非同期にこれらを行うようにしてもよい。
【図面の簡単な説明】
【００４６】
【図１】本発明を実施するためのハードウェア構成の説明図である。
【図２】本発明を実施するためのソフトウェア構成の説明図である。
【図３】Ｊａｖａ（Ｒ）オブジェクトをアロケートするための２つの領域を示す図である。
【図４】Ｊａｖａ（Ｒ）オブジェクトを本実施形態の方法によりアロケートする手順を示すフローチャートである。
【符号の説明】
【００４７】
１０…ＣＰＵ、１１…メモリ、１２…表示部、１３…入出力部、２０…Ｊａｖａ（Ｒ）アプリケーション、２１…ＡＭＳ、２２…クラスライブラリ、２３…プラットフォーム、２４…ＶＭ、２５…Ｊａｖａ（Ｒ）ヒープ領域、２５−１…第１の領域、２５−２…第２の領域、２６…ネイティブアプリケーション１、２７…ネイティブアプリケーション２。
【図１】
2006039878.tif 000003
【図２】
2006039878.tif 000004
【図３】
2006039878.tif 000005
【図４】
2006039878.tif 000006