JP2006525568A - 携帯型データ記憶媒体のメモリ管理 - Google Patents

Abstract

プログラム（３０）の実行中に生成されるオブジェクト（３８、４０、４４）を格納するための第１および第２のメモリ領域（３４、３６）を有する携帯型データ記憶媒体（１０）によってプログラム（３０）の実行中にメモリを管理する方法において、オブジェクト（３８、４０、４４）の少なくとも一部が第２のメモリ領域（３６）に作成される。更なるプログラム実行中に、オブジェクト（３８、４０、４４）への永続リファレンス（４２）が生成された場合、オブジェクトは第１のメモリ領域３４に転送される。ソースプログラム（８０）を実行可能なプログラム（３０）に変換するための方法において、コンパイル時に、新たに作成されるオブジェクト（３８、４０、４４）への永続リファレンス（４２）が生成されるか否かについての確認が実施される。確認の結果に応じて、オブジェクト（３８、４０、４４）を第１のメモリ領域（３４）かまたは少なくとも一部を第２のメモリ領域（３６）に作成するプログラムコードが生成される。本発明は、効率的に書き込めるメモリ領域の利用度を向上させる、携帯型データ記憶媒体中のメモリ管理技術を提供する。

Description

本発明は、広義には、プロセッサを有する携帯型データ記憶媒体によるプログラム実行中のメモリ管理の技術分野に関する。そのような種類の携帯型データ記憶媒体は、特に、さまざまな構造形態のチップカードまたはチップモジュールであり得る。さらに詳細には、本発明は、プログラム実行中に生成されるオブジェクトを記憶するために、データ記憶媒体の２つの異なるメモリ領域を使用することに関する。

一般に携帯型データ記憶媒体には、さまざまな記憶技術で構成された複数のメモリ領域が設けられている。一般に、メモリは、揮発性読出し／書込みメモリ（ＲＡＭ）、不揮発性書込可能メモリ（ＥＥＰＲＯＭ）およびマスクプログラム方式の固定メモリ（ＲＯＭ）に細分される。ＲＡＭへの書込み動作はＥＥＰＲＯＭへの書込み動作より大幅に少ない時間（例えば、３０分の１の時間）ですむ。他方では、データ記憶媒体の半導体チップ上で、ＲＡＭ内の１ビットはＥＥＰＲＯＭ内の１ビットよりもかなり大きなエリアを占めるので、通常、比較的小さいＲＡＭしか設けることができない。このため、高速であるが少ないＲＡＭを最善かつ最大にできる限りフレキシブルに利用するという課題が存在する。

複雑なメモリ管理機能を備えた携帯型データ記憶媒体は、例えばＪａｖａ Ｃａｒｄという商標で知られている。２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットでｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊａｖａｃａｒｄから入手可能な非特許文献１には、プログラム（「Ｊａｖａ Ｃａｒｄ」Ａｐｐｌｅｔ）実行用に「Ｊａｖａ Ｃａｒｄ」内に提供される環境について説明されている。第５章に、一般に永続オブジェクトがデータ記憶媒体のＥＥＰＲＯＭに格納されるのに対し、一般に一時オブジェクトはＲＡＭに作成されると記載されている。セキュリティ上の理由により、一時オブジェクトをＥＥＰＲＯＭに格納することは許されない。

上記の「Ｊａｖａ Ｃａｒｄ」のメモリ管理では、例えば、２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットで上記アドレスから入手可能な非特許文献２に記載されているように、一時オブジェクトを生成するために特殊なシステムコールが使用されるが、これによって一時オブジェクトの実用限界が制限されている。また、このような一時オブジェクトは潜在的に無限の寿命を備えている。ここで、「一時」という用語は、オブジェクトに格納されるデータを指しているに過ぎない。したがって、一時オブジェクトは、メモリ管理のフレキシビリティをわずかに増加させるだけである。

「Ｊａｖａ Ｃａｒｄ」プログラミングにおいて推奨される一般的な手法は、プログラム（アプレット）の寿命全体を通じて必要な全オブジェクトをプログラムインストール時に静的に生成するというものである。これは、「インストール」という指定名称を有するメソッドで実施される。しかしながら、この手法では、フレキシビリティの低いメモリ管理となり、したがって、最適なものではない。例えば、暗号化動作のための一時データを格納するために一時フィールドが作成されるとき、そのためにＲＡＭ内に静的に予約されたメモリスペースは一般に他のプログラムには利用できない。プログラム内で、このような予約メモリスペ―スを他のタスクにも使用できる範囲はプログラマの技量による。
したがって、ＲＡＭ内の少ないメモリスペースの利用度を向上させ、メモリ管理を自動化することが望まれる。
Ｊａｖａ Ｃａｒｄ（商標）実行環境（ＪＣＲＥ）仕様書（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ （ＪＣＲＥ） Ｓｐｅｃｉｆｉｃａｔｉｏｎ） Ｊａｖａ Ｃａｒｄ（商標）アプリケーション・プログラミング・インタフェース（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、８１〜８５ページ

そこで本発明の課題は、従来技術の問題の少なくとも一部分を解消すること、および、効率的に書き込めるメモリ領域（一般にＲＡＭメモリ）の利用度を向上させる、携帯型データ記憶媒体におけるメモリ管理法を提供することである。特に本発明は、プログラマをさほど煩わせずにＲＡＭメモリをフレキシブルに利用できるようにするものである。

本発明によれば、この課題の全体または一部は、請求項１に記載のプログラム実行中のメモリ管理方法、請求項７に記載のソースプログラム変換方法、請求項１２に記載の携帯型データ記憶媒体、および請求項１３に記載のコンピュータプログラム製品によって解決される。従属請求項は本発明の好ましい実施態様に関係する。

本発明の基礎をなす基本概念は、プログラム実行中に携帯型データ記憶媒体によって生成されるオブジェクトを、例えばＲＡＭなど、効率的に書き込めるメモリ領域に自動的に作成する、というものである。そのために、短寿命しか有しないオブジェクトについて考察した。そのような種類のオブジェクトを、本明細書では「ローカルオブジェクト」と呼ぶ。本発明で理解されるローカルオブジェクトは、例えば、例外発生時に生成される例外オブジェクトであり得る。例外オブジェクトの寿命は、該当の例外がキャッチされるとすぐに終わる。

本発明によれば、一時的に必要とされるメモリスペースを短期間、動的に（すなわち、ローカルオブジェクトの形態で）利用可能とすることができる。ローカルオブジェクトの一部または全体を、ＲＡＭまたは他の効率的に書き込めるメモリに作成する。本発明の自動ダイナミックメモリ管理の結果、メモリが十分に利用され、それにより、実行プログラムの処理速度およびこの実行プログラムが効率的に利用できるメモリスペースについて、データ記憶媒体の効率が増加する。

オブジェクトの寿命はオブジェクトへのリファレンスが無くなった時点で一般に終わりとなる。オブジェクトへのアクセスが不可能となるからである。詳細には、ローカルオブジェクトは、オブジェクトへの永続リファレンスが存在しないことによって宣言できる。本明細書では、「永続リファレンス」はオブジェクトへのリファレンスと理解され、このリファレンスはオブジェクトのフィールド、静的フィールド、またはアレイのフィールドに永続的に格納される。オブジェクトへのリファレンスが上記フィールドのうちの１つに書き込まれた途端に、このオブジェクトはもうローカルオブジェクトであり得ない。これに対し、例えばオペランドスタックまたはローカル変数に含まれているオブジェクトへの非永続リファレンスは、ローカルオブジェクトまたは非ローカルオブジェクトというオブジェクト分類に影響を及ぼさない。

オブジェクトをローカルオブジェクトとして処理すべきか、または非ローカルオブジェクトとして処理すべきかに関する判別は、プログラムのコンパイル時、実行時、または一部をコンパイル時で一部を実行時、に行うことができる。実行時に判別を行なう場合は、新たに生成するオブジェクトのうちの少なくともいくつかを、最初に、第２の効率的に書き込めるメモリ領域に作成する。更なるプログラム実行中に、オブジェクトへの永続リファレンスが作成されたかどうかの監視が行われる。オブジェクトへの永続リファレンスが作成された途端に、もうこのオブジェクトはローカルオブジェクトと見なされなくなる。その後、このオブジェクトを第１の不揮発性メモリ領域に転送する。

コンパイル時に判別を行なう場合は、ソースプログラムの一部、すなわち、オブジェクトへの永続リファレンスを作成するか否かのオブジェクト世代を含む部分、をコンパイラによって解析する。引き続きコンパイラは、この解析の結果に基づき、オブジェクトを第１のメモリ領域に作成するプログラムコードかまたは全部または一部を第２のメモリ領域に作成するプログラムコードを生成する。本明細書の用語法では、「コンパイラ」という用語は自動変換手順を実行するすべてのプログラムを含むものとする。したがって、「コンパイラ」は、狭い意味での「Ｊａｖａ」コンパイラのほかに、例えば、ＣＡＰファイル（カードアプリケーションファイル）および最適化プログラム生成用のコンバータのことも指すものとする。

コンパイル時のソースプログラム解析により、一般に、ただ１つの近似結果が得られる。このことは、不確実性の度合がローカルまたは非ローカルというオブジェクトの２分類のうちの一方と対応していることを意味すると理解される。したがって、確実にローカルであると認識されたオブジェクトだけを第２のメモリ領域に作成し、その他すべてのオブジェクトが第１のメモリ領域に作成するように準備することができる。これに対し、別の実施態様では、確実に非ローカルであると認識されるオブジェクトだけを第１のメモリ領域に作成し、その他すべてのオブジェクトを第２のメモリ領域に作成するように準備することができる。また、少なくとも確実にローカルであると分類できなかったオブジェクトに対して、前述の実行時監視を実施する。実施態様のうちのいくつかの形態において、オブジェクトをローカルまたは非ローカルと特徴付けることができるコンパイラ指示文（プラグラム）が提供される。

好ましい実施態様において、オブジェクトを第１のメモリ領域に作成すべきかまたは最初に第２のメモリ領域に作成すべきかを判断するために、簡素な基準が適用される。例えば、プログラムのインストールメソッドによって生成するオブジェクトを第１のメモリ領域に作成するように準備することができる。実施態様のさまざまな形態において、他のすべてのオブジェクトを最初に第２のメモリ領域に作成することも可能であるし、それぞれの種類のオブジェクトだけをそのようにすることも可能である。そのような種類のオブジェクトは、例えば、例外オブジェクトまたは暗号化動作のために一時的にのみ必要とされるオブジェクトであり得る。

ローカルオブジェクトの寿命は、通常、ローカルオブジェクトを生成したメソッドの−リターンまたは例外に由来する−終了とともに終わる。存在しているはずの、オブジェクトへのローカルリファレンスがこの瞬間に無くなるからである。その後、第２のメモリ領域内のオブジェクトにまだ必要なメモリスペースを解放できる。オブジェクトを生成したメソッドのリターンパラメータとしてオブジェクトを使用するとき、上記規則に対する例外が適用される。この場合、呼出しメソッドがオブジェクトへのリファレンスを受け取るので、少なくともこの呼出しメソッドが終了するまでオブジェクトが削除されることはない。

実施態様のいくつかの形態において、第２のメモリ領域の解放されたメモリスペースを新オブジェクトの作成に利用できるようにするために、メモリのクリーンアップ（カーベージコレクション）を行う。しかし、これはプログラム実行中に時間がかかり、実行時環境を複雑化する。そのため、第２のメモリ領域における占有状態を占有状態指標（Fuellstandszeigers）によって示す、特に簡素な方法が使用されることが好ましい。メソッドの終了時、通常、占有状態指標はメソッド呼出し時の状態にリセットされる。好ましい実施態様において、第２のメモリ領域の、リセットによって解放される部分が、メソッドのリターンパラメータとして使用されるオブジェクトを含んでいるときに限って規則に対する例外が作られる。

そのように要求された場合、オブジェクトを第２のメモリ領域から第１のメモリ領域に確実に転送できるようにするために、好ましくは第２のメモリ領域にオブジェクトが既に生成されているときに、オブジェクトのための十分なスペースが第１のメモリ領域で利用可能かどうかも確認する。また、更なるプログラムの実行中、新しいオブジェクトが作成されるときに、必要と考えられるオブジェクト転送のための十分なスペースが常に確実に第１のメモリ領域に存在していることが好ましい。

好ましい実施態様において、第１のメモリ領域がデータ記憶媒体のＥＥＰＲＯＭまたは他の不揮発性書込み可能メモリに置かれるのに対し、第２のメモリ領域はＲＡＭまたは他の効率的に書き込めるメモリに配される。第２のメモリ領域は、特にローカルヒープおよび／またはスタックメモリの形態とすることができる。既にコンパイル時にローカルオブジェクトと識別されたオブジェクトについては、スタックメモリに格納することが有利である。

本発明によるコンピュータプログラム製品は、本発明による変換方法を実施するためにプログラムコマンドを含んでいる。そのような種類のコンピュータプログラム製品は、本発明による方法を実施するためのプログラムを格納する、例えば半導体メモリまたはディスクまたはＣＤ−ＲＯＭなどの物理的媒体とすることができる。しかし、コンピュータプログラム製品は、例えばコンピュータネットワークによって転送される信号など、非物理的な媒体とすることもできる。コンピュータプログラム製品は、携帯型記憶媒体用のプログラムを生成するために一般的なワークステーションコンピュータによって実行されるコンパイラであることが好ましい。

好ましい実施態様において、データおよび／またはコンピュータプログラム製品は、前述および／または独立方法クレームに記載の特徴に対応する特徴を有している。

本発明のその他の特徴、利点および機能は、以下の例示実施形態および数多くの他の実施形態の具体的な説明から明らかになるであろう。添付図面を参照されたい。

図１に示されるデータ記憶媒体１０は、この例示実施形態では、「Ｊａｖａ Ｃａｒｄ」規格にしたがうチップカードの形態をしている。データ記憶媒体１０は、プロセッサ１２、さまざまな技術で構成された複数のメモリゾーン、および非接触式または接触式通信のためのインタフェース回路１４を１つの半導体チップ上に備えている。この例示実施形態では、固定メモリ１６、不揮発性書込み可能メモリ１８、および読出し／書込みメモリ２０がメモリゾーンとして設けられている。固定メモリ１６はマスクプログラム方式のＲＯＭの形態をしており、不揮発性メモリ１８は電気消去可能プログラマブルＥＥＰＲＯＭの形態をしており、読出し／書込みメモリ２０はＲＡＭの形態をしている。不揮発性メモリ１８への書込み動作は比較的面倒で、例えば、読出し／書込みメモリ２０への書込み動作の３０倍もの時間を要する。

データ記憶媒体１０の動作に必要なシステムプログラム２２は固定メモリ１６に含まれ、一部分は不揮発性メモリ１８にも含まれている。システムプログラム２２は、それ自体が公知となっている態様で、オペレーティングシステム２４を含み、また、この例示実施形態ではＪＣＶＭ（Ｊａｖａ Ｃａｒｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）の形態をしている仮想マシンを実施するプログラムコード２６も含んでいる。また、アプリケーション・プログラミング・インタフェースを利用できるようにするクラスライブラリ２８も設けられている。データ記憶媒体１０の初期設定時に、「Ｊａｖａ Ｃａｒｄ」アプレットの形態のプログラム３０が不揮発性メモリ１８にロードされるが、別の実施形態では、プログラムの全体または一部分を固定メモリ１６に置くことができる。図１には１つのプログラム３０しか示されていないが、もっと多くのプログラムを携帯型データ記憶媒体１０のプロセッサ１２に実行させるようにすることも可能である。プログラム３０は、下記で３０．ｘと総称される複数のメソッド３０．１、３０．２、３０．３、３０．４を含んでいる。メソッド３０．ｘは、それ自体が公知となっている態様で、プログラム３０をインストールするための「インストール」メソッドと呼ばれるメソッド、受信データパッケージを処理するための「プロセス」メソッドと呼ばれるメソッドを含み、また、データ記憶媒体１０の複数のプログラム間の変更時に呼び出される「選択」メソッドおよび「選択解除」メソッドを任意で含んでいる。

読出し／書込みメモリ２０にあるスタックメモリ３２は、プログラム実行中にオペランド、戻りアドレス、ローカル変数および他のデータ値を格納する。スタックメモリ３２の空き領域は、図１に斜線で示されている。不揮発性メモリ１８には、それ自体が公知となっている態様で永続ヒープの形態をしている第１のメモリ領域が確保されている。一般的な「Ｊａｖａ Ｃａｒｄ」アーキテクチャによれば、すべてのオブジェクト、静的データフィールドおよび非一時アレイがこの永続ヒープに形成される。これに対し、本例示実施形態では、永続ヒープは選択的にしか使用しない。短寿命しか有さず、永続リファレンスによる参照が行われていないローカルオブジェクトは、第１のメモリ領域３４ではなく、読出し／書込みメモリ２０の第２のメモリ領域３６に作成される。第２のメモリ領域３６は、永続ヒープと同様に、オブジェクトを格納する役割を果たすので、ローカルヒープとも呼ばれる。

上記状況を説明するために、一例として、第１のメモリ領域３４に形成され、それぞれ複数のデータフィールドを備えている２つのオブジェクト３８、４０が図１に示されている。第１のオブジェクト３８のデータフィールドのうちの１つは、第２のオブジェクト４０へのリファレンス４２を含んでいる。リファレンス４２は、永続格納されるデータフィールドに含まれているので「永続リファレンス」とも呼ばれる。第２のオブジェクト４０は、永続リファレンス４２によって参照されるため、ローカルオブジェクトではなく永続オブジェクトである。第２のメモリ領域３６には、一例として、ローカルオブジェクト４４が示されている。例えばスタックメモリ３２で形成されたローカル変数に含まれているローカルリファレンス４６は、ローカルオブジェクト４４を参照する。スタックメモリ３２内の別の値は占有状態指標４８として、第２のメモリ領域３６の空きメモリの開始を示す。この空きメモリは図１に斜線で示されている。

データ記憶媒体１０の実行中に、”ＮＥＷ”コマンドによって新オブジェクトの形成が要求されたときは、図２に示される手順が実施される。まず、ステップ５０で、新オブジェクトを作成するために十分なメモリスペースの空きが第１のメモリ領域にあるか否かの確認がなされる。利用できるメモリスペースが不十分な場合、エラーメッセージとともにオブジェクトの生成が中止される。本例示実施形態では、最初に第２のメモリ領域３６に作成されたオブジェクトでさえも第１のメモリ領域３４に確実に随時転送できるように、ステップ５０の確認は、作成されるオブジェクトの性質と無関係に実施される。

本例示実施形態では、プログラム３０の「インストール」メソッドによって作成されるオブジェクトは常に永続オブジェクトと見なされ、したがって、第１のメモリ領域３４に入れられようになっている。したがって、ステップ５２では、プログラムのインストールが現在実施されているか否かの照会が行われる。インストールが実施されていれば、ステップ５４で、新オブジェクトが第１のメモリ領域３４に永続オブジェクトとして生成される。ステップ５４で実施される生成手順は、一般的な「Ｊａｖａ Ｃａｒｄ」の場合に実施される永続ヒープにおけるオブジェクト作成に対応するものである。

ステップ５２でプログラム実行がインストールメソッド以外であることが確認された場合、本例示実施形態では、作成される新オブジェクトは、最初はローカルオブジェクトとして扱われる。その後、このオブジェクトは、十分なメモリスペースが空いていること（ステップ５６で確認される）を前提として、第２のメモリ領域３６（ローカルヒープ）に作成される。ローカルヒープで十分なメモリスペースが利用可能である場合、ステップ５８で、次の空き位置（これまで使っていた領域のすぐ隣の）にオブジェクトが作成され、これに応じて占有状態指標４８が更新される。しかし、ローカルヒープがすでにいっぱいになっている場合は、ステップ５４で、第１のメモリ領域３４にオブジェクトを作成するための一般的な手順が実施される。もちろん、この領域には、ステップ５０で確認された通り、利用可能な十分な空きメモリスペースがまだ残っている。

データ記憶媒体１０による更なるプログラム３０実行中、永続リファレンスが生成または変更されるたびに、このリファレンスが第２のメモリ領域３６にあるオブジェクトを参照しているか否かの確認が行われる。参照している場合、オブジェクトは第２のメモリ領域３６から第１のメモリ領域３４に転送される。ステップ５０の照会のため、オブジェクト転送が随時可能であることが保証されている。

本例示実施形態では、メソッド３０．ｘの終了後に、このメソッド３０．ｘで生成されたローカルオブジェクトが占有していたメモリスペースを簡単に解放できるように、第２のメモリ領域３６がスタックメモリと同様に構成されている。この手順を説明するため、一例として、いくつかのスタックフレーム６０．１、６０．２、６０．３によるスタックメモリ３２の占有状態を図３に示す。それ自体が公知となっている態様で、各メソッド３０．ｘが呼び出されると新しいスタックフレーム６０．ｘが作成されるが、メソッド３０．ｘの終了と同時に削除される。スタックフレ―ム６０．ｘには、呼出しメソッドへの戻りアドレス、管理および機密データが格納され、また、呼び出されたメソッドのローカル変数も任意で格納される。

本例示実施形態では、各スタックフレーム６０．ｘに、当該メソッド３０．ｘの実行中に占有状態指標４８を入れる占有状態フィールド(Fuellstandsfeld)６２．ｘも設けられている。一例として示されている図３の図では、占有状態フィールド６２．３が最新の占有状態指標４８を含み、占有状態フィールド６２．２がスタックフレーム６０．３に対応するメソッドが呼び出された時点で最新であった占有状態を含んでいる。６４．３の部分は、呼び出されたために現在実施されているメソッドが新たに占有しているローカルヒープの一部分を指している。ローカルヒープ内の６４．１および６４．２の部分は、呼び出しによってメモリフレーム６０．１および６０．２の作成を生じさせたメソッドで埋められている。

ここに記載されている例示実施形態では、メソッドによって占有された、第２のメモリ領域３６内のスペースを、メソッドの終了時に完全に解放するようになっている。これは、メソッド終了時に、対応するスタックフレーム６０．ｘ（占有状態フィールド６２．ｘを含んでいる）を処分し、占有内容が内部に格納されている次に古いスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を新占有状態指標４８として使用することによって、難なく行われる。したがって、例えば、呼出しによってスタックフレーム６０．３の形成を生じさせるメソッドの終了後、占有状態フィールド６２．２の内容が新占有状態指標４８として使用されるので、メモリ部分６４．３全体が解放される。

終了したばかりのメソッドが第２のメモリ領域３６に作成されたローカルオブジェクトへのリファレンスを呼出しメソッドにリターンする場合に、上記パラグラフに記載された規則に対する例外が存在する。この場合、ローカルオブジェクトが上書きされないようにするために、最新の占有状態フィールド６２．ｘの内容が次に古いスタックフレーム６０．（ｘ−１）にコピーされる。例えば、図３のメモリ占有配置では、メモリフレーム６０．３を作成したメソッドが、メモリ領域６４．３にあるオブジェクトへのリファレンスをリターンする場合、前のスタックフレーム６０．２の占有状態フィールド６２．２に占有状態フィールド６２．３の値がコピーされる。

メソッド終了時の上記手順を図４に再度図解する。ステップ７０の結果に応じて、直前のスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を復活させられるか（ステップ７２）か、または最新の占有状態指標４８の値を直前のスタックフレーム６０．（ｘ−１）に引き継がされる。

図５は、コンパイラ８２によって「Ｊａｖａ」ソースプログラム８０をＣＡＰファイル（カードアプリケーションファイル）８４に変換する、それ自体が公知である変換手順を示す。ＣＡＰファイル８４は、次に、例えばデータ記憶媒体１０の初期設定時に、ローディングプログラム８６によってデータ記憶媒体１０にプログラム３０としてロードされる。本明細書に記載される例示実施形態では、コンパイラ８２は、ソースプログラム８０をバイトコードに変換するための実際のコンパイルモジュールのほかに、さまざまな正確性チェックを実施する、「オフカード仮想マシン」とも呼ばれるコンバータを備えている。

前述の方法では、新たに作成されるオブジェクトを第１のメモリ領域３４に生成すべきか第２のメモリ領域３６に作成すべきかを決定するために、ステップ５２で、実行時に簡単な照会が実施された。また、永続リファレンスの作成および更新時には、別の実行時チェックが実施された。これに対し、別の実施形態では、前記チェックは、全体的または部分的に、コンパイラ８２のレベルに対して行われる。

コンパイラ８２は、ソースプログラム８０または中間コードの抽象解析により、後のプログラム実行中に新しく作成されるオブジェクトをローカルオブジェクトと見なすべきか、非ローカルオブジェクトと見なすべきかに関する情報を得ることができる。引き続きコンパイラ８２は、この分析結果に基づき、第１のメモリ領域３４または第２のメモリ領域３６にオブジェクトを作成させるプログラムコードを生成する。別の実施形態では、コンパイル時に確実にローカルであると認識された、ローカル変数などのオブジェクトがスタックメモリ３２に作成される。これらの実施形態のスタックメモリ３２は、ローカルヒープを読出し／書込みメモリ２０に付加的に供給するか否かに応じて、第２のメモリ領域３６の全体または第２のメモリ領域３６の一部分を形成する。

ソースプログラム８０は、通常、コンパイル時にローカルオブジェクトまたは非ローカルオブジェクトとはっきり分類できないオブジェクトを生成するためのコマンドを有する。そのようなオブジェクトは、第１のメモリ領域３４に直ちに作成することもできるし、前述の態様で、最初に第２のメモリ領域３６にローカルオブジェクトとして作成し、必要となったときに第１のメモリ領域３４に転送するだけとすることもできる。

本発明の例示実施形態にしたがう携帯型データ記憶媒体のブロック図である。 新オブジェクト作成時に実施される手順の流れ図である。 一例として、プログラム実行中のスタックメモリおよびローカルヒープのメモリ占有状態を示す図である。 メソッド終了時に実施される手順の流れ図である。 実行可能なプログラムへのソースプログラムの変換を示す概略図である。

符号の説明

１０ データ記憶媒体
１２ プロセッサ
１４ インタフェース回路
１６ 固定メモリ
１８ 不揮発性メモリ
２０ 読出し／書込みメモリ
３０ プログラム
３２ スタックメモリ
３４ 第１のメモリ領域
３６ 第２のメモリ領域
３８、４０、４４ オブジェクト
４２ 永続リファレンス
４８ 占有状態指標

Claims (13)

1. プログラム（３０）の実行中に生成されるオブジェクト（３８、４０、４４）を格納するための第１および第２のメモリ領域（３４、３６）を有する携帯型データ記憶媒体（１０）によって前記プログラム（３０）の実行中にメモリを管理する方法であって、前記第２のメモリ領域（３６）への書込み動作が前記第１のメモリ領域（３４）への書込み動作よりも効率的に実施される方法であり、
   プログラム実行中に生成されるオブジェクト（３８、４０、４４）の少なくとも一部を前記第２のメモリ領域（３６）に作成するステップと、
   更なるプログラム実行中に、前記オブジェクト（３８、４０、４４）への永続リファレンス（４２）が生成された場合に、前記オブジェクト（３８、４０、４４）を前記第１のメモリ領域３４に転送するステップと
   を備えることを特徴とする方法。
2. 前記オブジェクト（３８、４０、４４）が前記プログラム（３０）のメソッド（３０．ｘ）の実行中に生成され、前記メソッド（３０．ｘ）の終了時に、少なくとも前記メソッド（３０．ｘ）が前記オブジェクトへのリファレンスをリターンしないときに、前記オブジェクト（３８、４０、４４）によってまだ占有されている前記第２のメモリ領域（３６）のメモリスペースを解放することを特徴とする請求項１に記載の方法。
3. 前記メソッド（３０．ｘ）の終了時に、少なくともメソッド（３０．ｘ）が、前記第２のメモリ領域（３６）に置かれたオブジェクト（３８、４０、４４）へのリファレンスをリターンしないときに、第２のメモリ領域（３６）の占有状態を示す占有状態指標（４８）を、メソッド（３０．ｘ）が呼び出された時点の最新レベルにリセットすることを特徴とする請求項２に記載の方法。
4. オブジェクト（３８、４０、４４）を前記第２のメモリ領域（３６）に作成するときに、必要となるであろう前記オブジェクト（３８、４０、４４）の転送のための十分なスペースが第１のメモリ領域（３４）内で利用できるか否か確認することを特徴とする請求項１〜３のいずれか１項に記載の方法。
5. 前記プログラム（３０）のインストール中に生成するオブジェクト（３８、４０、４４）を前記第１のメモリ領域（３６）に作成することを特徴とする請求項１〜４のいずれか１項に記載の方法。
6. ソースプログラム（８０）からの前記プログラム（３０）の生成時にローカルオブジェクトと識別されたオブジェクト（３８、４０、４４）だけを、最初に前記第２のメモリ領域（３６）に作成することを特徴とする請求項１〜５のいずれか１項に記載の方法。
7. ソースプログラム（８０）を、携帯型データ記憶媒体（１０）によって実行されるようになっているプログラム（３０）に変換する方法であって、前記データ記憶媒体（１０）が、前記プログラム（３０）の実行中に生成されるオブジェクト（３８、４０、４４）を格納するための第１および第２のメモリ領域（３４、３６）を有し、前記第２のメモリ領域（３６）への書込み動作が前記第１のメモリ領域（３４）への書込み動作よりも効率的に実施される方法において、
   前記ソースプログラム（８０）の、前記オブジェクト（３８、４０、４４）の生成を含む部分の変換時に、前記オブジェクト（３８、４０、４４）への永続リファレンス（４２）が前記ソースプログラム（８０）の被変換部分に生成されたか否かを少なくともおおよそ確認し、この確認の結果に応じて、前記オブジェクト（３８、４０、４４）を前記第１のメモリ領域（３４）に作成するプログラムコードを生成するか、または前記オブジェクト（３８、４０、４４）の少なくとも一部を前記第２のメモリ領域（３６）に作成するプログラムコードを生成することを特徴とする方法。
8. 生成された前記プログラム（３０）が、前記携帯型データ記憶媒体（１０）による実行時に実行されるようになっていることを特徴とする請求項１〜７のいずれか１項に記載の方法。
9. 前記第２のメモリ領域（３６）に形成されるオブジェクト（３８、４０、４４）が、一時的にのみ必要とされるローカルオブジェクトであることを特徴とする請求項１〜８のいずれか１項に記載の方法。
10. 前記第２のメモリ領域（３６）がローカルヒープとスタックメモリ（３２）の両方または一方を備えていることを特徴とする請求項１〜９のいずれか１項に記載の方法。
11. 前記データ記憶媒体（１０）が「Ｊａｖａ Ｃａｒｄ」であり、前記プログラム（３０）が「Ｊａｖａ Ｃａｒｄ」アプレットであることを特徴とする請求項１〜１０のいずれか１項に記載の方法。
12. プロセッサ（１２）および少なくとも１つのメモリ（１６、１８、２０）を有し、前記メモリ（１６、１８、２０）が、請求項１〜６にしたがう方法を前記プロセッサ（１２）に実施させるプログラムコマンドを含んでいることを特徴とする、チップカードまたはチップモジュールなどの携帯型データ記憶媒体（１０）。
13. 請求項７または請求項８に記載の特徴を有する方法をコンピュータに実施させるプログラムコマンドを備えていることを特徴とする、コンパイラ（８２）などのコンピュータプログラム製品。

Images