携帯型データ記憶媒体のメモリ管理
【課題】プログラムの実行中に生成されるオブジェクトを格納するための第１および第２のメモリ領域を有する携帯型データ記憶媒体によってプログラムの実行中にメモリを管理する。
【解決手段】オブジェクト（３８、４０、４４）の少なくとも一部が第２のメモリ領域（３６）に作成される。更なるプログラム実行中に、オブジェクト（３８、４０、４４）への永続リファレンス（４２）が生成された場合、オブジェクトは第１のメモリ領域３４に転送される。実行によりオブジェクトを作成した特定のメソッドの終了時に、特定のメソッドが、解放されるべき第２のメモリ領域のメモリスペースに存在するオブジェクトへのリファレンスをリターンしないときに、第２のメモリ領域の占有状態を示す占有状態指標を特定のメソッドが呼び出された時点における占有状態にリセットすることにより、第２のメモリ領域のメモリスペースを特定のメソッドが呼び出された時点のレベルまで解放する。
【解決手段】オブジェクト（３８、４０、４４）の少なくとも一部が第２のメモリ領域（３６）に作成される。更なるプログラム実行中に、オブジェクト（３８、４０、４４）への永続リファレンス（４２）が生成された場合、オブジェクトは第１のメモリ領域３４に転送される。実行によりオブジェクトを作成した特定のメソッドの終了時に、特定のメソッドが、解放されるべき第２のメモリ領域のメモリスペースに存在するオブジェクトへのリファレンスをリターンしないときに、第２のメモリ領域の占有状態を示す占有状態指標を特定のメソッドが呼び出された時点における占有状態にリセットすることにより、第２のメモリ領域のメモリスペースを特定のメソッドが呼び出された時点のレベルまで解放する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広義には、プロセッサを有する携帯型データ記憶媒体によるプログラム実行中のメモリ管理の技術分野に関する。そのような種類の携帯型データ記憶媒体は、特に、さまざまな構造形態のチップカードまたはチップモジュールであり得る。さらに詳細には、本発明は、プログラム実行中に生成されるオブジェクトを記憶するために、データ記憶媒体の２つの異なるメモリ領域を使用することに関する。
【背景技術】
【０００２】
一般に携帯型データ記憶媒体には、さまざまな記憶技術で構成された複数のメモリ領域が設けられている。一般に、メモリは、揮発性読出し／書込みメモリ（ＲＡＭ）、不揮発性書込可能メモリ（ＥＥＰＲＯＭ）およびマスクプログラム方式の固定メモリ（ＲＯＭ）に細分される。ＲＡＭへの書込み動作はＥＥＰＲＯＭへの書込み動作より大幅に少ない時間（例えば、３０分の１の時間）ですむ。他方では、データ記憶媒体の半導体チップ上で、ＲＡＭ内の１ビットはＥＥＰＲＯＭ内の１ビットよりもかなり大きなエリアを占めるので、通常、比較的小さいＲＡＭしか設けることができない。このため、高速であるが少ないＲＡＭを最善かつ最大にできる限りフレキシブルに利用するという課題が存在する。
【０００３】
複雑なメモリ管理機能を備えた携帯型データ記憶媒体は、例えばＪａｖａ Ｃａｒｄという商標で知られている。２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットでｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊａｖａｃａｒｄから入手可能な非特許文献１には、プログラム（「Ｊａｖａ Ｃａｒｄ」Ａｐｐｌｅｔ）実行用に「Ｊａｖａ Ｃａｒｄ」内に提供される環境について説明されている。第５章に、一般に永続オブジェクトがデータ記憶媒体のＥＥＰＲＯＭに格納されるのに対し、一般に一時オブジェクトはＲＡＭに作成されると記載されている。セキュリティ上の理由により、一時オブジェクトをＥＥＰＲＯＭに格納することは許されない。
【０００４】
上記の「Ｊａｖａ Ｃａｒｄ」のメモリ管理では、例えば、２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットで上記アドレスから入手可能な非特許文献２に記載されているように、一時オブジェクトを生成するために特殊なシステムコールが使用されるが、これによって一時オブジェクトの実用限界が制限されている。また、このような一時オブジェクトは潜在的に無限の寿命を備えている。ここで、「一時」という用語は、オブジェクトに格納されるデータを指しているに過ぎない。したがって、一時オブジェクトは、メモリ管理のフレキシビリティをわずかに増加させるだけである。
【０００５】
「Ｊａｖａ Ｃａｒｄ」プログラミングにおいて推奨される一般的な手法は、プログラム（アプレット）の寿命全体を通じて必要な全オブジェクトをプログラムインストール時に静的に生成するというものである。これは、「インストール」という指定名称を有するメソッドで実施される。しかしながら、この手法では、フレキシビリティの低いメモリ管理となり、したがって、最適なものではない。例えば、暗号化動作のための一時データを格納するために一時フィールドが作成されるとき、そのためにＲＡＭ内に静的に予約されたメモリスペースは一般に他のプログラムには利用できない。プログラム内で、このような予約メモリスペ―スを他のタスクにも使用できる範囲はプログラマの技量による。
したがって、ＲＡＭ内の少ないメモリスペースの利用度を向上させ、メモリ管理を自動化することが望まれる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｊａｖａ Ｃａｒｄ（商標）実行環境（ＪＣＲＥ）仕様書（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ （ＪＣＲＥ） Ｓｐｅｃｉｆｉｃａｔｉｏｎ）
【非特許文献２】Ｊａｖａ Ｃａｒｄ（商標）アプリケーション・プログラミング・インタフェース（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、８１〜８５ページ
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで本発明の課題は、従来技術の問題の少なくとも一部分を解消すること、および、効率的に書き込めるメモリ領域（一般にＲＡＭメモリ）の利用度を向上させる、携帯型データ記憶媒体におけるメモリ管理法を提供することである。特に本発明は、プログラマをさほど煩わせずにＲＡＭメモリをフレキシブルに利用できるようにするものである。
【課題を解決するための手段】
【０００８】
本発明によれば、この課題の全体または一部は、請求項１に記載のプログラム実行中のメモリ管理方法、請求項７に記載のソースプログラム変換方法、請求項１２に記載の携帯型データ記憶媒体、および請求項１３に記載のコンピュータプログラム製品によって解決される。従属請求項は本発明の好ましい実施態様に関係する。
【０００９】
本発明の基礎をなす基本概念は、プログラム実行中に携帯型データ記憶媒体によって生成されるオブジェクトを、例えばＲＡＭなど、効率的に書き込めるメモリ領域に自動的に作成する、というものである。そのために、短寿命しか有しないオブジェクトについて考察した。そのような種類のオブジェクトを、本明細書では「ローカルオブジェクト」と呼ぶ。本発明で理解されるローカルオブジェクトは、例えば、例外発生時に生成される例外オブジェクトであり得る。例外オブジェクトの寿命は、該当の例外がキャッチされるとすぐに終わる。
【００１０】
本発明によれば、一時的に必要とされるメモリスペースを短期間、動的に（すなわち、ローカルオブジェクトの形態で）利用可能とすることができる。ローカルオブジェクトの一部または全体を、ＲＡＭまたは他の効率的に書き込めるメモリに作成する。本発明の自動ダイナミックメモリ管理の結果、メモリが十分に利用され、それにより、実行プログラムの処理速度およびこの実行プログラムが効率的に利用できるメモリスペースについて、データ記憶媒体の効率が増加する。
【００１１】
オブジェクトの寿命はオブジェクトへのリファレンスが無くなった時点で一般に終わりとなる。オブジェクトへのアクセスが不可能となるからである。詳細には、ローカルオブジェクトは、オブジェクトへの永続リファレンスが存在しないことによって宣言できる。本明細書では、「永続リファレンス」はオブジェクトへのリファレンスと理解され、このリファレンスはオブジェクトのフィールド、静的フィールド、またはアレイのフィールドに永続的に格納される。オブジェクトへのリファレンスが上記フィールドのうちの１つに書き込まれた途端に、このオブジェクトはもうローカルオブジェクトであり得ない。これに対し、例えばオペランドスタックまたはローカル変数に含まれているオブジェクトへの非永続リファレンスは、ローカルオブジェクトまたは非ローカルオブジェクトというオブジェクト分類に影響を及ぼさない。
【００１２】
オブジェクトをローカルオブジェクトとして処理すべきか、または非ローカルオブジェクトとして処理すべきかに関する判別は、プログラムのコンパイル時、実行時、または一部をコンパイル時で一部を実行時、に行うことができる。実行時に判別を行なう場合は、新たに生成するオブジェクトのうちの少なくともいくつかを、最初に、第２の効率的に書き込めるメモリ領域に作成する。更なるプログラム実行中に、オブジェクトへの永続リファレンスが作成されたかどうかの監視が行われる。オブジェクトへの永続リファレンスが作成された途端に、もうこのオブジェクトはローカルオブジェクトと見なされなくなる。その後、このオブジェクトを第１の不揮発性メモリ領域に転送する。
【００１３】
コンパイル時に判別を行なう場合は、ソースプログラムの一部、すなわち、オブジェクトへの永続リファレンスを作成するか否かのオブジェクト世代を含む部分、をコンパイラによって解析する。引き続きコンパイラは、この解析の結果に基づき、オブジェクトを第１のメモリ領域に作成するプログラムコードかまたは全部または一部を第２のメモリ領域に作成するプログラムコードを生成する。本明細書の用語法では、「コンパイラ」という用語は自動変換手順を実行するすべてのプログラムを含むものとする。したがって、「コンパイラ」は、狭い意味での「Ｊａｖａ」コンパイラのほかに、例えば、ＣＡＰファイル（カードアプリケーションファイル）および最適化プログラム生成用のコンバータのことも指すものとする。
【００１４】
コンパイル時のソースプログラム解析により、一般に、ただ１つの近似結果が得られる。このことは、不確実性の度合がローカルまたは非ローカルというオブジェクトの２分類のうちの一方と対応していることを意味すると理解される。したがって、確実にローカルであると認識されたオブジェクトだけを第２のメモリ領域に作成し、その他すべてのオブジェクトが第１のメモリ領域に作成するように準備することができる。これに対し、別の実施態様では、確実に非ローカルであると認識されるオブジェクトだけを第１のメモリ領域に作成し、その他すべてのオブジェクトを第２のメモリ領域に作成するように準備することができる。また、少なくとも確実にローカルであると分類できなかったオブジェクトに対して、前述の実行時監視を実施する。実施態様のうちのいくつかの形態において、オブジェクトをローカルまたは非ローカルと特徴付けることができるコンパイラ指示文（プラグラム）が提供される。
【００１５】
好ましい実施態様において、オブジェクトを第１のメモリ領域に作成すべきかまたは最初に第２のメモリ領域に作成すべきかを判断するために、簡素な基準が適用される。例えば、プログラムのインストールメソッドによって生成するオブジェクトを第１のメモリ領域に作成するように準備することができる。実施態様のさまざまな形態において、他のすべてのオブジェクトを最初に第２のメモリ領域に作成することも可能であるし、それぞれの種類のオブジェクトだけをそのようにすることも可能である。そのような種類のオブジェクトは、例えば、例外オブジェクトまたは暗号化動作のために一時的にのみ必要とされるオブジェクトであり得る。
【００１６】
ローカルオブジェクトの寿命は、通常、ローカルオブジェクトを生成したメソッドの−リターンまたは例外に由来する−終了とともに終わる。存在しているはずの、オブジェクトへのローカルリファレンスがこの瞬間に無くなるからである。その後、第２のメモリ領域内のオブジェクトにまだ必要なメモリスペースを解放できる。オブジェクトを生成したメソッドのリターンパラメータとしてオブジェクトを使用するとき、上記規則に対する例外が適用される。この場合、呼出しメソッドがオブジェクトへのリファレンスを受け取るので、少なくともこの呼出しメソッドが終了するまでオブジェクトが削除されることはない。
【００１７】
実施態様のいくつかの形態において、第２のメモリ領域の解放されたメモリスペースを新オブジェクトの作成に利用できるようにするために、メモリのクリーンアップ（カーベージコレクション）を行う。しかし、これはプログラム実行中に時間がかかり、実行時環境を複雑化する。そのため、第２のメモリ領域における占有状態を占有状態指標（Fuellstandszeigers）によって示す、特に簡素な方法が使用されることが好ましい。メソッドの終了時、通常、占有状態指標はメソッド呼出し時の状態にリセットされる。好ましい実施態様において、第２のメモリ領域の、リセットによって解放される部分が、メソッドのリターンパラメータとして使用されるオブジェクトを含んでいるときに限って規則に対する例外が作られる。
【００１８】
そのように要求された場合、オブジェクトを第２のメモリ領域から第１のメモリ領域に確実に転送できるようにするために、好ましくは第２のメモリ領域にオブジェクトが既に生成されているときに、オブジェクトのための十分なスペースが第１のメモリ領域で利用可能かどうかも確認する。また、更なるプログラムの実行中、新しいオブジェクトが作成されるときに、必要と考えられるオブジェクト転送のための十分なスペースが常に確実に第１のメモリ領域に存在していることが好ましい。
【００１９】
好ましい実施態様において、第１のメモリ領域がデータ記憶媒体のＥＥＰＲＯＭまたは他の不揮発性書込み可能メモリに置かれるのに対し、第２のメモリ領域はＲＡＭまたは他の効率的に書き込めるメモリに配される。第２のメモリ領域は、特にローカルヒープおよび／またはスタックメモリの形態とすることができる。既にコンパイル時にローカルオブジェクトと識別されたオブジェクトについては、スタックメモリに格納することが有利である。
【００２０】
本発明によるコンピュータプログラム製品は、本発明による変換方法を実施するためにプログラムコマンドを含んでいる。そのような種類のコンピュータプログラム製品は、本発明による方法を実施するためのプログラムを格納する、例えば半導体メモリまたはディスクまたはＣＤ−ＲＯＭなどの物理的媒体とすることができる。しかし、コンピュータプログラム製品は、例えばコンピュータネットワークによって転送される信号など、非物理的な媒体とすることもできる。コンピュータプログラム製品は、携帯型記憶媒体用のプログラムを生成するために一般的なワークステーションコンピュータによって実行されるコンパイラであることが好ましい。
【００２１】
好ましい実施態様において、データおよび／またはコンピュータプログラム製品は、前述および／または独立方法クレームに記載の特徴に対応する特徴を有している。
【００２２】
本発明のその他の特徴、利点および機能は、以下の例示実施形態および数多くの他の実施形態の具体的な説明から明らかになるであろう。添付図面を参照されたい。
【図面の簡単な説明】
【００２３】
【図１】本発明の例示実施形態にしたがう携帯型データ記憶媒体のブロック図である。
【図２】新オブジェクト作成時に実施される手順の流れ図である。
【図３】一例として、プログラム実行中のスタックメモリおよびローカルヒープのメモリ占有状態を示す図である。
【図４】メソッド終了時に実施される手順の流れ図である。
【図５】実行可能なプログラムへのソースプログラムの変換を示す概略図である。
【発明を実施するための形態】
【００２４】
図１に示されるデータ記憶媒体１０は、この例示実施形態では、「Ｊａｖａ Ｃａｒｄ」規格にしたがうチップカードの形態をしている。データ記憶媒体１０は、プロセッサ１２、さまざまな技術で構成された複数のメモリゾーン、および非接触式または接触式通信のためのインタフェース回路１４を１つの半導体チップ上に備えている。この例示実施形態では、固定メモリ１６、不揮発性書込み可能メモリ１８、および読出し／書込みメモリ２０がメモリゾーンとして設けられている。固定メモリ１６はマスクプログラム方式のＲＯＭの形態をしており、不揮発性メモリ１８は電気消去可能プログラマブルＥＥＰＲＯＭの形態をしており、読出し／書込みメモリ２０はＲＡＭの形態をしている。不揮発性メモリ１８への書込み動作は比較的面倒で、例えば、読出し／書込みメモリ２０への書込み動作の３０倍もの時間を要する。
【００２５】
データ記憶媒体１０の動作に必要なシステムプログラム２２は固定メモリ１６に含まれ、一部分は不揮発性メモリ１８にも含まれている。システムプログラム２２は、それ自体が公知となっている態様で、オペレーティングシステム２４を含み、また、この例示実施形態ではＪＣＶＭ（Ｊａｖａ Ｃａｒｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）の形態をしている仮想マシンを実施するプログラムコード２６も含んでいる。また、アプリケーション・プログラミング・インタフェースを利用できるようにするクラスライブラリ２８も設けられている。データ記憶媒体１０の初期設定時に、「Ｊａｖａ Ｃａｒｄ」アプレットの形態のプログラム３０が不揮発性メモリ１８にロードされるが、別の実施形態では、プログラムの全体または一部分を固定メモリ１６に置くことができる。図１には１つのプログラム３０しか示されていないが、もっと多くのプログラムを携帯型データ記憶媒体１０のプロセッサ１２に実行させるようにすることも可能である。プログラム３０は、下記で３０．ｘと総称される複数のメソッド３０．１、３０．２、３０．３、３０．４を含んでいる。メソッド３０．ｘは、それ自体が公知となっている態様で、プログラム３０をインストールするための「インストール」メソッドと呼ばれるメソッド、受信データパッケージを処理するための「プロセス」メソッドと呼ばれるメソッドを含み、また、データ記憶媒体１０の複数のプログラム間の変更時に呼び出される「選択」メソッドおよび「選択解除」メソッドを任意で含んでいる。
【００２６】
読出し／書込みメモリ２０にあるスタックメモリ３２は、プログラム実行中にオペランド、戻りアドレス、ローカル変数および他のデータ値を格納する。スタックメモリ３２の空き領域は、図１に斜線で示されている。不揮発性メモリ１８には、それ自体が公知となっている態様で永続ヒープの形態をしている第１のメモリ領域が確保されている。一般的な「Ｊａｖａ Ｃａｒｄ」アーキテクチャによれば、すべてのオブジェクト、静的データフィールドおよび非一時アレイがこの永続ヒープに形成される。これに対し、本例示実施形態では、永続ヒープは選択的にしか使用しない。短寿命しか有さず、永続リファレンスによる参照が行われていないローカルオブジェクトは、第１のメモリ領域３４ではなく、読出し／書込みメモリ２０の第２のメモリ領域３６に作成される。第２のメモリ領域３６は、永続ヒープと同様に、オブジェクトを格納する役割を果たすので、ローカルヒープとも呼ばれる。
【００２７】
上記状況を説明するために、一例として、第１のメモリ領域３４に形成され、それぞれ複数のデータフィールドを備えている２つのオブジェクト３８、４０が図１に示されている。第１のオブジェクト３８のデータフィールドのうちの１つは、第２のオブジェクト４０へのリファレンス４２を含んでいる。リファレンス４２は、永続格納されるデータフィールドに含まれているので「永続リファレンス」とも呼ばれる。第２のオブジェクト４０は、永続リファレンス４２によって参照されるため、ローカルオブジェクトではなく永続オブジェクトである。第２のメモリ領域３６には、一例として、ローカルオブジェクト４４が示されている。例えばスタックメモリ３２で形成されたローカル変数に含まれているローカルリファレンス４６は、ローカルオブジェクト４４を参照する。スタックメモリ３２内の別の値は占有状態指標４８として、第２のメモリ領域３６の空きメモリの開始を示す。この空きメモリは図１に斜線で示されている。
【００２８】
データ記憶媒体１０の実行中に、”ＮＥＷ”コマンドによって新オブジェクトの形成が要求されたときは、図２に示される手順が実施される。まず、ステップ５０で、新オブジェクトを作成するために十分なメモリスペースの空きが第１のメモリ領域にあるか否かの確認がなされる。利用できるメモリスペースが不十分な場合、エラーメッセージとともにオブジェクトの生成が中止される。本例示実施形態では、最初に第２のメモリ領域３６に作成されたオブジェクトでさえも第１のメモリ領域３４に確実に随時転送できるように、ステップ５０の確認は、作成されるオブジェクトの性質と無関係に実施される。
【００２９】
本例示実施形態では、プログラム３０の「インストール」メソッドによって作成されるオブジェクトは常に永続オブジェクトと見なされ、したがって、第１のメモリ領域３４に入れられようになっている。したがって、ステップ５２では、プログラムのインストールが現在実施されているか否かの照会が行われる。インストールが実施されていれば、ステップ５４で、新オブジェクトが第１のメモリ領域３４に永続オブジェクトとして生成される。ステップ５４で実施される生成手順は、一般的な「Ｊａｖａ Ｃａｒｄ」の場合に実施される永続ヒープにおけるオブジェクト作成に対応するものである。
【００３０】
ステップ５２でプログラム実行がインストールメソッド以外であることが確認された場合、本例示実施形態では、作成される新オブジェクトは、最初はローカルオブジェクトとして扱われる。その後、このオブジェクトは、十分なメモリスペースが空いていること（ステップ５６で確認される）を前提として、第２のメモリ領域３６（ローカルヒープ）に作成される。ローカルヒープで十分なメモリスペースが利用可能である場合、ステップ５８で、次の空き位置（これまで使っていた領域のすぐ隣の）にオブジェクトが作成され、これに応じて占有状態指標４８が更新される。しかし、ローカルヒープがすでにいっぱいになっている場合は、ステップ５４で、第１のメモリ領域３４にオブジェクトを作成するための一般的な手順が実施される。もちろん、この領域には、ステップ５０で確認された通り、利用可能な十分な空きメモリスペースがまだ残っている。
【００３１】
データ記憶媒体１０による更なるプログラム３０実行中、永続リファレンスが生成または変更されるたびに、このリファレンスが第２のメモリ領域３６にあるオブジェクトを参照しているか否かの確認が行われる。参照している場合、オブジェクトは第２のメモリ領域３６から第１のメモリ領域３４に転送される。ステップ５０の照会のため、オブジェクト転送が随時可能であることが保証されている。
【００３２】
本例示実施形態では、メソッド３０．ｘの終了後に、このメソッド３０．ｘで生成されたローカルオブジェクトが占有していたメモリスペースを簡単に解放できるように、第２のメモリ領域３６がスタックメモリと同様に構成されている。この手順を説明するため、一例として、いくつかのスタックフレーム６０．１、６０．２、６０．３によるスタックメモリ３２の占有状態を図３に示す。それ自体が公知となっている態様で、各メソッド３０．ｘが呼び出されると新しいスタックフレーム６０．ｘが作成されるが、メソッド３０．ｘの終了と同時に削除される。スタックフレ―ム６０．ｘには、呼出しメソッドへの戻りアドレス、管理および機密データが格納され、また、呼び出されたメソッドのローカル変数も任意で格納される。
【００３３】
本例示実施形態では、各スタックフレーム６０．ｘに、当該メソッド３０．ｘの実行中に占有状態指標４８を入れる占有状態フィールド(Fuellstandsfeld)６２．ｘも設けられている。一例として示されている図３の図では、占有状態フィールド６２．３が最新の占有状態指標４８を含み、占有状態フィールド６２．２がスタックフレーム６０．３に対応するメソッドが呼び出された時点で最新であった占有状態を含んでいる。６４．３の部分は、呼び出されたために現在実施されているメソッドが新たに占有しているローカルヒープの一部分を指している。ローカルヒープ内の６４．１および６４．２の部分は、呼び出しによってメモリフレーム６０．１および６０．２の作成を生じさせたメソッドで埋められている。
【００３４】
ここに記載されている例示実施形態では、メソッドによって占有された、第２のメモリ領域３６内のスペースを、メソッドの終了時に完全に解放するようになっている。これは、メソッド終了時に、対応するスタックフレーム６０．ｘ（占有状態フィールド６２．ｘを含んでいる）を処分し、占有内容が内部に格納されている次に古いスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を新占有状態指標４８として使用することによって、難なく行われる。したがって、例えば、呼出しによってスタックフレーム６０．３の形成を生じさせるメソッドの終了後、占有状態フィールド６２．２の内容が新占有状態指標４８として使用されるので、メモリ部分６４．３全体が解放される。
【００３５】
終了したばかりのメソッドが第２のメモリ領域３６に作成されたローカルオブジェクトへのリファレンスを呼出しメソッドにリターンする場合に、上記パラグラフに記載された規則に対する例外が存在する。この場合、ローカルオブジェクトが上書きされないようにするために、最新の占有状態フィールド６２．ｘの内容が次に古いスタックフレーム６０．（ｘ−１）にコピーされる。例えば、図３のメモリ占有配置では、メモリフレーム６０．３を作成したメソッドが、メモリ領域６４．３にあるオブジェクトへのリファレンスをリターンする場合、前のスタックフレーム６０．２の占有状態フィールド６２．２に占有状態フィールド６２．３の値がコピーされる。
【００３６】
メソッド終了時の上記手順を図４に再度図解する。ステップ７０の結果に応じて、直前のスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を復活させられるか（ステップ７２）か、または最新の占有状態指標４８の値を直前のスタックフレーム６０．（ｘ−１）に引き継がされる。
【００３７】
図５は、コンパイラ８２によって「Ｊａｖａ」ソースプログラム８０をＣＡＰファイル（カードアプリケーションファイル）８４に変換する、それ自体が公知である変換手順を示す。ＣＡＰファイル８４は、次に、例えばデータ記憶媒体１０の初期設定時に、ローディングプログラム８６によってデータ記憶媒体１０にプログラム３０としてロードされる。本明細書に記載される例示実施形態では、コンパイラ８２は、ソースプログラム８０をバイトコードに変換するための実際のコンパイルモジュールのほかに、さまざまな正確性チェックを実施する、「オフカード仮想マシン」とも呼ばれるコンバータを備えている。
【００３８】
前述の方法では、新たに作成されるオブジェクトを第１のメモリ領域３４に生成すべきか第２のメモリ領域３６に作成すべきかを決定するために、ステップ５２で、実行時に簡単な照会が実施された。また、永続リファレンスの作成および更新時には、別の実行時チェックが実施された。これに対し、別の実施形態では、前記チェックは、全体的または部分的に、コンパイラ８２のレベルに対して行われる。
【００３９】
コンパイラ８２は、ソースプログラム８０または中間コードの抽象解析により、後のプログラム実行中に新しく作成されるオブジェクトをローカルオブジェクトと見なすべきか、非ローカルオブジェクトと見なすべきかに関する情報を得ることができる。引き続きコンパイラ８２は、この分析結果に基づき、第１のメモリ領域３４または第２のメモリ領域３６にオブジェクトを作成させるプログラムコードを生成する。別の実施形態では、コンパイル時に確実にローカルであると認識された、ローカル変数などのオブジェクトがスタックメモリ３２に作成される。これらの実施形態のスタックメモリ３２は、ローカルヒープを読出し／書込みメモリ２０に付加的に供給するか否かに応じて、第２のメモリ領域３６の全体または第２のメモリ領域３６の一部分を形成する。
【００４０】
ソースプログラム８０は、通常、コンパイル時にローカルオブジェクトまたは非ローカルオブジェクトとはっきり分類できないオブジェクトを生成するためのコマンドを有する。そのようなオブジェクトは、第１のメモリ領域３４に直ちに作成することもできるし、前述の態様で、最初に第２のメモリ領域３６にローカルオブジェクトとして作成し、必要となったときに第１のメモリ領域３４に転送するだけとすることもできる。
【符号の説明】
【００４１】
１０ データ記憶媒体
１２ プロセッサ
１４ インタフェース回路
１６ 固定メモリ
１８ 不揮発性メモリ
２０ 読出し／書込みメモリ
３０ プログラム
３２ スタックメモリ
３４ 第１のメモリ領域
３６ 第２のメモリ領域
３８、４０、４４ オブジェクト
４２ 永続リファレンス
４８ 占有状態指標
【技術分野】
【０００１】
本発明は、広義には、プロセッサを有する携帯型データ記憶媒体によるプログラム実行中のメモリ管理の技術分野に関する。そのような種類の携帯型データ記憶媒体は、特に、さまざまな構造形態のチップカードまたはチップモジュールであり得る。さらに詳細には、本発明は、プログラム実行中に生成されるオブジェクトを記憶するために、データ記憶媒体の２つの異なるメモリ領域を使用することに関する。
【背景技術】
【０００２】
一般に携帯型データ記憶媒体には、さまざまな記憶技術で構成された複数のメモリ領域が設けられている。一般に、メモリは、揮発性読出し／書込みメモリ（ＲＡＭ）、不揮発性書込可能メモリ（ＥＥＰＲＯＭ）およびマスクプログラム方式の固定メモリ（ＲＯＭ）に細分される。ＲＡＭへの書込み動作はＥＥＰＲＯＭへの書込み動作より大幅に少ない時間（例えば、３０分の１の時間）ですむ。他方では、データ記憶媒体の半導体チップ上で、ＲＡＭ内の１ビットはＥＥＰＲＯＭ内の１ビットよりもかなり大きなエリアを占めるので、通常、比較的小さいＲＡＭしか設けることができない。このため、高速であるが少ないＲＡＭを最善かつ最大にできる限りフレキシブルに利用するという課題が存在する。
【０００３】
複雑なメモリ管理機能を備えた携帯型データ記憶媒体は、例えばＪａｖａ Ｃａｒｄという商標で知られている。２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットでｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊａｖａｃａｒｄから入手可能な非特許文献１には、プログラム（「Ｊａｖａ Ｃａｒｄ」Ａｐｐｌｅｔ）実行用に「Ｊａｖａ Ｃａｒｄ」内に提供される環境について説明されている。第５章に、一般に永続オブジェクトがデータ記憶媒体のＥＥＰＲＯＭに格納されるのに対し、一般に一時オブジェクトはＲＡＭに作成されると記載されている。セキュリティ上の理由により、一時オブジェクトをＥＥＰＲＯＭに格納することは許されない。
【０００４】
上記の「Ｊａｖａ Ｃａｒｄ」のメモリ管理では、例えば、２００２年６月に米国パロアルトの企業サン・マイクロシステム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．）によって公表され、インターネットで上記アドレスから入手可能な非特許文献２に記載されているように、一時オブジェクトを生成するために特殊なシステムコールが使用されるが、これによって一時オブジェクトの実用限界が制限されている。また、このような一時オブジェクトは潜在的に無限の寿命を備えている。ここで、「一時」という用語は、オブジェクトに格納されるデータを指しているに過ぎない。したがって、一時オブジェクトは、メモリ管理のフレキシビリティをわずかに増加させるだけである。
【０００５】
「Ｊａｖａ Ｃａｒｄ」プログラミングにおいて推奨される一般的な手法は、プログラム（アプレット）の寿命全体を通じて必要な全オブジェクトをプログラムインストール時に静的に生成するというものである。これは、「インストール」という指定名称を有するメソッドで実施される。しかしながら、この手法では、フレキシビリティの低いメモリ管理となり、したがって、最適なものではない。例えば、暗号化動作のための一時データを格納するために一時フィールドが作成されるとき、そのためにＲＡＭ内に静的に予約されたメモリスペースは一般に他のプログラムには利用できない。プログラム内で、このような予約メモリスペ―スを他のタスクにも使用できる範囲はプログラマの技量による。
したがって、ＲＡＭ内の少ないメモリスペースの利用度を向上させ、メモリ管理を自動化することが望まれる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｊａｖａ Ｃａｒｄ（商標）実行環境（ＪＣＲＥ）仕様書（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ （ＪＣＲＥ） Ｓｐｅｃｉｆｉｃａｔｉｏｎ）
【非特許文献２】Ｊａｖａ Ｃａｒｄ（商標）アプリケーション・プログラミング・インタフェース（Ｊａｖａ ＣａｒｄＴＭ ２．２ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、８１〜８５ページ
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで本発明の課題は、従来技術の問題の少なくとも一部分を解消すること、および、効率的に書き込めるメモリ領域（一般にＲＡＭメモリ）の利用度を向上させる、携帯型データ記憶媒体におけるメモリ管理法を提供することである。特に本発明は、プログラマをさほど煩わせずにＲＡＭメモリをフレキシブルに利用できるようにするものである。
【課題を解決するための手段】
【０００８】
本発明によれば、この課題の全体または一部は、請求項１に記載のプログラム実行中のメモリ管理方法、請求項７に記載のソースプログラム変換方法、請求項１２に記載の携帯型データ記憶媒体、および請求項１３に記載のコンピュータプログラム製品によって解決される。従属請求項は本発明の好ましい実施態様に関係する。
【０００９】
本発明の基礎をなす基本概念は、プログラム実行中に携帯型データ記憶媒体によって生成されるオブジェクトを、例えばＲＡＭなど、効率的に書き込めるメモリ領域に自動的に作成する、というものである。そのために、短寿命しか有しないオブジェクトについて考察した。そのような種類のオブジェクトを、本明細書では「ローカルオブジェクト」と呼ぶ。本発明で理解されるローカルオブジェクトは、例えば、例外発生時に生成される例外オブジェクトであり得る。例外オブジェクトの寿命は、該当の例外がキャッチされるとすぐに終わる。
【００１０】
本発明によれば、一時的に必要とされるメモリスペースを短期間、動的に（すなわち、ローカルオブジェクトの形態で）利用可能とすることができる。ローカルオブジェクトの一部または全体を、ＲＡＭまたは他の効率的に書き込めるメモリに作成する。本発明の自動ダイナミックメモリ管理の結果、メモリが十分に利用され、それにより、実行プログラムの処理速度およびこの実行プログラムが効率的に利用できるメモリスペースについて、データ記憶媒体の効率が増加する。
【００１１】
オブジェクトの寿命はオブジェクトへのリファレンスが無くなった時点で一般に終わりとなる。オブジェクトへのアクセスが不可能となるからである。詳細には、ローカルオブジェクトは、オブジェクトへの永続リファレンスが存在しないことによって宣言できる。本明細書では、「永続リファレンス」はオブジェクトへのリファレンスと理解され、このリファレンスはオブジェクトのフィールド、静的フィールド、またはアレイのフィールドに永続的に格納される。オブジェクトへのリファレンスが上記フィールドのうちの１つに書き込まれた途端に、このオブジェクトはもうローカルオブジェクトであり得ない。これに対し、例えばオペランドスタックまたはローカル変数に含まれているオブジェクトへの非永続リファレンスは、ローカルオブジェクトまたは非ローカルオブジェクトというオブジェクト分類に影響を及ぼさない。
【００１２】
オブジェクトをローカルオブジェクトとして処理すべきか、または非ローカルオブジェクトとして処理すべきかに関する判別は、プログラムのコンパイル時、実行時、または一部をコンパイル時で一部を実行時、に行うことができる。実行時に判別を行なう場合は、新たに生成するオブジェクトのうちの少なくともいくつかを、最初に、第２の効率的に書き込めるメモリ領域に作成する。更なるプログラム実行中に、オブジェクトへの永続リファレンスが作成されたかどうかの監視が行われる。オブジェクトへの永続リファレンスが作成された途端に、もうこのオブジェクトはローカルオブジェクトと見なされなくなる。その後、このオブジェクトを第１の不揮発性メモリ領域に転送する。
【００１３】
コンパイル時に判別を行なう場合は、ソースプログラムの一部、すなわち、オブジェクトへの永続リファレンスを作成するか否かのオブジェクト世代を含む部分、をコンパイラによって解析する。引き続きコンパイラは、この解析の結果に基づき、オブジェクトを第１のメモリ領域に作成するプログラムコードかまたは全部または一部を第２のメモリ領域に作成するプログラムコードを生成する。本明細書の用語法では、「コンパイラ」という用語は自動変換手順を実行するすべてのプログラムを含むものとする。したがって、「コンパイラ」は、狭い意味での「Ｊａｖａ」コンパイラのほかに、例えば、ＣＡＰファイル（カードアプリケーションファイル）および最適化プログラム生成用のコンバータのことも指すものとする。
【００１４】
コンパイル時のソースプログラム解析により、一般に、ただ１つの近似結果が得られる。このことは、不確実性の度合がローカルまたは非ローカルというオブジェクトの２分類のうちの一方と対応していることを意味すると理解される。したがって、確実にローカルであると認識されたオブジェクトだけを第２のメモリ領域に作成し、その他すべてのオブジェクトが第１のメモリ領域に作成するように準備することができる。これに対し、別の実施態様では、確実に非ローカルであると認識されるオブジェクトだけを第１のメモリ領域に作成し、その他すべてのオブジェクトを第２のメモリ領域に作成するように準備することができる。また、少なくとも確実にローカルであると分類できなかったオブジェクトに対して、前述の実行時監視を実施する。実施態様のうちのいくつかの形態において、オブジェクトをローカルまたは非ローカルと特徴付けることができるコンパイラ指示文（プラグラム）が提供される。
【００１５】
好ましい実施態様において、オブジェクトを第１のメモリ領域に作成すべきかまたは最初に第２のメモリ領域に作成すべきかを判断するために、簡素な基準が適用される。例えば、プログラムのインストールメソッドによって生成するオブジェクトを第１のメモリ領域に作成するように準備することができる。実施態様のさまざまな形態において、他のすべてのオブジェクトを最初に第２のメモリ領域に作成することも可能であるし、それぞれの種類のオブジェクトだけをそのようにすることも可能である。そのような種類のオブジェクトは、例えば、例外オブジェクトまたは暗号化動作のために一時的にのみ必要とされるオブジェクトであり得る。
【００１６】
ローカルオブジェクトの寿命は、通常、ローカルオブジェクトを生成したメソッドの−リターンまたは例外に由来する−終了とともに終わる。存在しているはずの、オブジェクトへのローカルリファレンスがこの瞬間に無くなるからである。その後、第２のメモリ領域内のオブジェクトにまだ必要なメモリスペースを解放できる。オブジェクトを生成したメソッドのリターンパラメータとしてオブジェクトを使用するとき、上記規則に対する例外が適用される。この場合、呼出しメソッドがオブジェクトへのリファレンスを受け取るので、少なくともこの呼出しメソッドが終了するまでオブジェクトが削除されることはない。
【００１７】
実施態様のいくつかの形態において、第２のメモリ領域の解放されたメモリスペースを新オブジェクトの作成に利用できるようにするために、メモリのクリーンアップ（カーベージコレクション）を行う。しかし、これはプログラム実行中に時間がかかり、実行時環境を複雑化する。そのため、第２のメモリ領域における占有状態を占有状態指標（Fuellstandszeigers）によって示す、特に簡素な方法が使用されることが好ましい。メソッドの終了時、通常、占有状態指標はメソッド呼出し時の状態にリセットされる。好ましい実施態様において、第２のメモリ領域の、リセットによって解放される部分が、メソッドのリターンパラメータとして使用されるオブジェクトを含んでいるときに限って規則に対する例外が作られる。
【００１８】
そのように要求された場合、オブジェクトを第２のメモリ領域から第１のメモリ領域に確実に転送できるようにするために、好ましくは第２のメモリ領域にオブジェクトが既に生成されているときに、オブジェクトのための十分なスペースが第１のメモリ領域で利用可能かどうかも確認する。また、更なるプログラムの実行中、新しいオブジェクトが作成されるときに、必要と考えられるオブジェクト転送のための十分なスペースが常に確実に第１のメモリ領域に存在していることが好ましい。
【００１９】
好ましい実施態様において、第１のメモリ領域がデータ記憶媒体のＥＥＰＲＯＭまたは他の不揮発性書込み可能メモリに置かれるのに対し、第２のメモリ領域はＲＡＭまたは他の効率的に書き込めるメモリに配される。第２のメモリ領域は、特にローカルヒープおよび／またはスタックメモリの形態とすることができる。既にコンパイル時にローカルオブジェクトと識別されたオブジェクトについては、スタックメモリに格納することが有利である。
【００２０】
本発明によるコンピュータプログラム製品は、本発明による変換方法を実施するためにプログラムコマンドを含んでいる。そのような種類のコンピュータプログラム製品は、本発明による方法を実施するためのプログラムを格納する、例えば半導体メモリまたはディスクまたはＣＤ−ＲＯＭなどの物理的媒体とすることができる。しかし、コンピュータプログラム製品は、例えばコンピュータネットワークによって転送される信号など、非物理的な媒体とすることもできる。コンピュータプログラム製品は、携帯型記憶媒体用のプログラムを生成するために一般的なワークステーションコンピュータによって実行されるコンパイラであることが好ましい。
【００２１】
好ましい実施態様において、データおよび／またはコンピュータプログラム製品は、前述および／または独立方法クレームに記載の特徴に対応する特徴を有している。
【００２２】
本発明のその他の特徴、利点および機能は、以下の例示実施形態および数多くの他の実施形態の具体的な説明から明らかになるであろう。添付図面を参照されたい。
【図面の簡単な説明】
【００２３】
【図１】本発明の例示実施形態にしたがう携帯型データ記憶媒体のブロック図である。
【図２】新オブジェクト作成時に実施される手順の流れ図である。
【図３】一例として、プログラム実行中のスタックメモリおよびローカルヒープのメモリ占有状態を示す図である。
【図４】メソッド終了時に実施される手順の流れ図である。
【図５】実行可能なプログラムへのソースプログラムの変換を示す概略図である。
【発明を実施するための形態】
【００２４】
図１に示されるデータ記憶媒体１０は、この例示実施形態では、「Ｊａｖａ Ｃａｒｄ」規格にしたがうチップカードの形態をしている。データ記憶媒体１０は、プロセッサ１２、さまざまな技術で構成された複数のメモリゾーン、および非接触式または接触式通信のためのインタフェース回路１４を１つの半導体チップ上に備えている。この例示実施形態では、固定メモリ１６、不揮発性書込み可能メモリ１８、および読出し／書込みメモリ２０がメモリゾーンとして設けられている。固定メモリ１６はマスクプログラム方式のＲＯＭの形態をしており、不揮発性メモリ１８は電気消去可能プログラマブルＥＥＰＲＯＭの形態をしており、読出し／書込みメモリ２０はＲＡＭの形態をしている。不揮発性メモリ１８への書込み動作は比較的面倒で、例えば、読出し／書込みメモリ２０への書込み動作の３０倍もの時間を要する。
【００２５】
データ記憶媒体１０の動作に必要なシステムプログラム２２は固定メモリ１６に含まれ、一部分は不揮発性メモリ１８にも含まれている。システムプログラム２２は、それ自体が公知となっている態様で、オペレーティングシステム２４を含み、また、この例示実施形態ではＪＣＶＭ（Ｊａｖａ Ｃａｒｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）の形態をしている仮想マシンを実施するプログラムコード２６も含んでいる。また、アプリケーション・プログラミング・インタフェースを利用できるようにするクラスライブラリ２８も設けられている。データ記憶媒体１０の初期設定時に、「Ｊａｖａ Ｃａｒｄ」アプレットの形態のプログラム３０が不揮発性メモリ１８にロードされるが、別の実施形態では、プログラムの全体または一部分を固定メモリ１６に置くことができる。図１には１つのプログラム３０しか示されていないが、もっと多くのプログラムを携帯型データ記憶媒体１０のプロセッサ１２に実行させるようにすることも可能である。プログラム３０は、下記で３０．ｘと総称される複数のメソッド３０．１、３０．２、３０．３、３０．４を含んでいる。メソッド３０．ｘは、それ自体が公知となっている態様で、プログラム３０をインストールするための「インストール」メソッドと呼ばれるメソッド、受信データパッケージを処理するための「プロセス」メソッドと呼ばれるメソッドを含み、また、データ記憶媒体１０の複数のプログラム間の変更時に呼び出される「選択」メソッドおよび「選択解除」メソッドを任意で含んでいる。
【００２６】
読出し／書込みメモリ２０にあるスタックメモリ３２は、プログラム実行中にオペランド、戻りアドレス、ローカル変数および他のデータ値を格納する。スタックメモリ３２の空き領域は、図１に斜線で示されている。不揮発性メモリ１８には、それ自体が公知となっている態様で永続ヒープの形態をしている第１のメモリ領域が確保されている。一般的な「Ｊａｖａ Ｃａｒｄ」アーキテクチャによれば、すべてのオブジェクト、静的データフィールドおよび非一時アレイがこの永続ヒープに形成される。これに対し、本例示実施形態では、永続ヒープは選択的にしか使用しない。短寿命しか有さず、永続リファレンスによる参照が行われていないローカルオブジェクトは、第１のメモリ領域３４ではなく、読出し／書込みメモリ２０の第２のメモリ領域３６に作成される。第２のメモリ領域３６は、永続ヒープと同様に、オブジェクトを格納する役割を果たすので、ローカルヒープとも呼ばれる。
【００２７】
上記状況を説明するために、一例として、第１のメモリ領域３４に形成され、それぞれ複数のデータフィールドを備えている２つのオブジェクト３８、４０が図１に示されている。第１のオブジェクト３８のデータフィールドのうちの１つは、第２のオブジェクト４０へのリファレンス４２を含んでいる。リファレンス４２は、永続格納されるデータフィールドに含まれているので「永続リファレンス」とも呼ばれる。第２のオブジェクト４０は、永続リファレンス４２によって参照されるため、ローカルオブジェクトではなく永続オブジェクトである。第２のメモリ領域３６には、一例として、ローカルオブジェクト４４が示されている。例えばスタックメモリ３２で形成されたローカル変数に含まれているローカルリファレンス４６は、ローカルオブジェクト４４を参照する。スタックメモリ３２内の別の値は占有状態指標４８として、第２のメモリ領域３６の空きメモリの開始を示す。この空きメモリは図１に斜線で示されている。
【００２８】
データ記憶媒体１０の実行中に、”ＮＥＷ”コマンドによって新オブジェクトの形成が要求されたときは、図２に示される手順が実施される。まず、ステップ５０で、新オブジェクトを作成するために十分なメモリスペースの空きが第１のメモリ領域にあるか否かの確認がなされる。利用できるメモリスペースが不十分な場合、エラーメッセージとともにオブジェクトの生成が中止される。本例示実施形態では、最初に第２のメモリ領域３６に作成されたオブジェクトでさえも第１のメモリ領域３４に確実に随時転送できるように、ステップ５０の確認は、作成されるオブジェクトの性質と無関係に実施される。
【００２９】
本例示実施形態では、プログラム３０の「インストール」メソッドによって作成されるオブジェクトは常に永続オブジェクトと見なされ、したがって、第１のメモリ領域３４に入れられようになっている。したがって、ステップ５２では、プログラムのインストールが現在実施されているか否かの照会が行われる。インストールが実施されていれば、ステップ５４で、新オブジェクトが第１のメモリ領域３４に永続オブジェクトとして生成される。ステップ５４で実施される生成手順は、一般的な「Ｊａｖａ Ｃａｒｄ」の場合に実施される永続ヒープにおけるオブジェクト作成に対応するものである。
【００３０】
ステップ５２でプログラム実行がインストールメソッド以外であることが確認された場合、本例示実施形態では、作成される新オブジェクトは、最初はローカルオブジェクトとして扱われる。その後、このオブジェクトは、十分なメモリスペースが空いていること（ステップ５６で確認される）を前提として、第２のメモリ領域３６（ローカルヒープ）に作成される。ローカルヒープで十分なメモリスペースが利用可能である場合、ステップ５８で、次の空き位置（これまで使っていた領域のすぐ隣の）にオブジェクトが作成され、これに応じて占有状態指標４８が更新される。しかし、ローカルヒープがすでにいっぱいになっている場合は、ステップ５４で、第１のメモリ領域３４にオブジェクトを作成するための一般的な手順が実施される。もちろん、この領域には、ステップ５０で確認された通り、利用可能な十分な空きメモリスペースがまだ残っている。
【００３１】
データ記憶媒体１０による更なるプログラム３０実行中、永続リファレンスが生成または変更されるたびに、このリファレンスが第２のメモリ領域３６にあるオブジェクトを参照しているか否かの確認が行われる。参照している場合、オブジェクトは第２のメモリ領域３６から第１のメモリ領域３４に転送される。ステップ５０の照会のため、オブジェクト転送が随時可能であることが保証されている。
【００３２】
本例示実施形態では、メソッド３０．ｘの終了後に、このメソッド３０．ｘで生成されたローカルオブジェクトが占有していたメモリスペースを簡単に解放できるように、第２のメモリ領域３６がスタックメモリと同様に構成されている。この手順を説明するため、一例として、いくつかのスタックフレーム６０．１、６０．２、６０．３によるスタックメモリ３２の占有状態を図３に示す。それ自体が公知となっている態様で、各メソッド３０．ｘが呼び出されると新しいスタックフレーム６０．ｘが作成されるが、メソッド３０．ｘの終了と同時に削除される。スタックフレ―ム６０．ｘには、呼出しメソッドへの戻りアドレス、管理および機密データが格納され、また、呼び出されたメソッドのローカル変数も任意で格納される。
【００３３】
本例示実施形態では、各スタックフレーム６０．ｘに、当該メソッド３０．ｘの実行中に占有状態指標４８を入れる占有状態フィールド(Fuellstandsfeld)６２．ｘも設けられている。一例として示されている図３の図では、占有状態フィールド６２．３が最新の占有状態指標４８を含み、占有状態フィールド６２．２がスタックフレーム６０．３に対応するメソッドが呼び出された時点で最新であった占有状態を含んでいる。６４．３の部分は、呼び出されたために現在実施されているメソッドが新たに占有しているローカルヒープの一部分を指している。ローカルヒープ内の６４．１および６４．２の部分は、呼び出しによってメモリフレーム６０．１および６０．２の作成を生じさせたメソッドで埋められている。
【００３４】
ここに記載されている例示実施形態では、メソッドによって占有された、第２のメモリ領域３６内のスペースを、メソッドの終了時に完全に解放するようになっている。これは、メソッド終了時に、対応するスタックフレーム６０．ｘ（占有状態フィールド６２．ｘを含んでいる）を処分し、占有内容が内部に格納されている次に古いスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を新占有状態指標４８として使用することによって、難なく行われる。したがって、例えば、呼出しによってスタックフレーム６０．３の形成を生じさせるメソッドの終了後、占有状態フィールド６２．２の内容が新占有状態指標４８として使用されるので、メモリ部分６４．３全体が解放される。
【００３５】
終了したばかりのメソッドが第２のメモリ領域３６に作成されたローカルオブジェクトへのリファレンスを呼出しメソッドにリターンする場合に、上記パラグラフに記載された規則に対する例外が存在する。この場合、ローカルオブジェクトが上書きされないようにするために、最新の占有状態フィールド６２．ｘの内容が次に古いスタックフレーム６０．（ｘ−１）にコピーされる。例えば、図３のメモリ占有配置では、メモリフレーム６０．３を作成したメソッドが、メモリ領域６４．３にあるオブジェクトへのリファレンスをリターンする場合、前のスタックフレーム６０．２の占有状態フィールド６２．２に占有状態フィールド６２．３の値がコピーされる。
【００３６】
メソッド終了時の上記手順を図４に再度図解する。ステップ７０の結果に応じて、直前のスタックフレーム６０．（ｘ−１）の占有状態フィールド６２．（ｘ−１）を復活させられるか（ステップ７２）か、または最新の占有状態指標４８の値を直前のスタックフレーム６０．（ｘ−１）に引き継がされる。
【００３７】
図５は、コンパイラ８２によって「Ｊａｖａ」ソースプログラム８０をＣＡＰファイル（カードアプリケーションファイル）８４に変換する、それ自体が公知である変換手順を示す。ＣＡＰファイル８４は、次に、例えばデータ記憶媒体１０の初期設定時に、ローディングプログラム８６によってデータ記憶媒体１０にプログラム３０としてロードされる。本明細書に記載される例示実施形態では、コンパイラ８２は、ソースプログラム８０をバイトコードに変換するための実際のコンパイルモジュールのほかに、さまざまな正確性チェックを実施する、「オフカード仮想マシン」とも呼ばれるコンバータを備えている。
【００３８】
前述の方法では、新たに作成されるオブジェクトを第１のメモリ領域３４に生成すべきか第２のメモリ領域３６に作成すべきかを決定するために、ステップ５２で、実行時に簡単な照会が実施された。また、永続リファレンスの作成および更新時には、別の実行時チェックが実施された。これに対し、別の実施形態では、前記チェックは、全体的または部分的に、コンパイラ８２のレベルに対して行われる。
【００３９】
コンパイラ８２は、ソースプログラム８０または中間コードの抽象解析により、後のプログラム実行中に新しく作成されるオブジェクトをローカルオブジェクトと見なすべきか、非ローカルオブジェクトと見なすべきかに関する情報を得ることができる。引き続きコンパイラ８２は、この分析結果に基づき、第１のメモリ領域３４または第２のメモリ領域３６にオブジェクトを作成させるプログラムコードを生成する。別の実施形態では、コンパイル時に確実にローカルであると認識された、ローカル変数などのオブジェクトがスタックメモリ３２に作成される。これらの実施形態のスタックメモリ３２は、ローカルヒープを読出し／書込みメモリ２０に付加的に供給するか否かに応じて、第２のメモリ領域３６の全体または第２のメモリ領域３６の一部分を形成する。
【００４０】
ソースプログラム８０は、通常、コンパイル時にローカルオブジェクトまたは非ローカルオブジェクトとはっきり分類できないオブジェクトを生成するためのコマンドを有する。そのようなオブジェクトは、第１のメモリ領域３４に直ちに作成することもできるし、前述の態様で、最初に第２のメモリ領域３６にローカルオブジェクトとして作成し、必要となったときに第１のメモリ領域３４に転送するだけとすることもできる。
【符号の説明】
【００４１】
１０ データ記憶媒体
１２ プロセッサ
１４ インタフェース回路
１６ 固定メモリ
１８ 不揮発性メモリ
２０ 読出し／書込みメモリ
３０ プログラム
３２ スタックメモリ
３４ 第１のメモリ領域
３６ 第２のメモリ領域
３８、４０、４４ オブジェクト
４２ 永続リファレンス
４８ 占有状態指標
【特許請求の範囲】
【請求項１】
プログラムの実行中に生成されるオブジェクトを格納するための第１および第２のメモリ領域を有する携帯型データ記憶媒体によって前記プログラムの実行中にメモリを管理する方法であって、前記第２のメモリ領域への書込み動作が前記第１のメモリ領域への書込み動作よりも高速に実施される方法であり、
プログラムの特定のメソッド実行の結果として生成されるオブジェクトの少なくとも一部を前記第２のメモリ領域に作成するステップと、
更なるプログラムの実行中に、前記オブジェクトへの永続的に格納されたリファレンスが生成されたかどうかを監視するステップ、
更なるプログラム実行中に、前記オブジェクトへの永続的に格納されたリファレンスが生成された場合に、前記オブジェクトを前記第１のメモリ領域に転送するステップと、
前記実行によりオブジェクトを作成した前記特定のメソッドの終了時に、第２のメモリ領域を解放するステップであって、少なくとも前記特定のメソッドが、解放されるべき第２のメモリ領域のメモリスペースに存在するオブジェクトへのリファレンスをリターンしないときに、前記第２のメモリ領域の占有状態を示す占有状態指標を前記特定のメソッドが呼び出された時点における占有状態にリセットすることで、前記第２のメモリ領域のメモリスペースを前記特定のメソッドが呼び出された時点のレベルまで解放するステップとを有することを特徴とする方法。
【請求項２】
前記永続的なリファレンスが生成されたどうかを監視するステップが、前記永続的に可能されたリファレンスが生成され、または修正されるたびに実行されることを特徴とする請求項１に記載の方法。
【請求項３】
オブジェクトを前記第２のメモリ領域に作成するときに、必要となるであろう前記オブジェクトの転送のための十分なスペースが第１のメモリ領域内で利用できるか否か確認することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記プログラムのインストール中に生成するオブジェクトを前記第１のメモリ領域に作成することを特徴とする請求項１〜３のいずれか１項に記載の方法。
【請求項５】
ソースプログラムからの前記プログラムの生成時にローカルオブジェクトと識別されたオブジェクトだけを、最初に前記第２のメモリ領域に作成することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記オブジェクトが、例外発生時に生成される例外オブジェクトであることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項７】
前記オブジェクトが、暗号化動作のために一時的に必要とされるオブジェクトであることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項８】
前記特定のメソッドが、受信データパケットを処理するためのプロセスメソッドであることを特徴とする請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記特定のメソッドが、データ記憶媒体の複数のプログラム間の変更時に呼び出される選択または選択解除メソッドとは異なるメソッドであることを特徴とする請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記占有状態指標のリセットによる第２のメモリ領域のメモリスペースの解放は、ガベージコレクションの処理とは異なることを特徴とする請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
コンパイラにより、ソースプログラムを、携帯型データ記憶媒体によって実行されるようになっているプログラムに変換する方法であって、前記データ記憶媒体が、前記プログラムの実行中に生成されるオブジェクトを格納するための第１および第２のメモリ領域を有し、前記第２のメモリ領域への書込み動作が前記第１のメモリ領域への書込み動作よりも高速に実施される方法において、
前記ソースプログラムの、前記オブジェクトの生成をもたらす部分の変換に際して、前記コンパイラが前記ソースプログラムの部分を解析し、前記オブジェクトへの永続的に格納されたリファレンスが、前記ソースプログラムの被変換部分に後続するプログラム実行の間に生成される否かを判断し、該判断の結果に応じて、前記コンパイラが、前記オブジェクトを前記第１のメモリ領域に作成するプログラムコードを生成するか、または前記オブジェクトの少なくとも一部を前記第２のメモリ領域に作成するプログラムコードを生成することを特徴とする方法。
【請求項１２】
生成された前記プログラムが前記携帯型データ記憶媒体によって実行されることで、請求項１〜１０のいずれか１項に係る方法が実行されるようになっていることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第２のメモリ領域に形成されるオブジェクトが、一時的にのみ必要とされるローカルオブジェクトであることを特徴とする請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記第２のメモリ領域が、ローカルヒープ形式のメモリ領域であることを特徴とする請求項１〜１３のいずれか１項に記載の方法。
【請求項１５】
前記第２のメモリ領域が、スタックメモリ内に配置されることを特徴とする請求項１から１４のいずれか１項に記載の方法。
【請求項１６】
前記データ記憶媒体が「Ｊａｖａ Ｃａｒｄ」であり、前記プログラムが「Ｊａｖａ Ｃａｒｄ」アプレットであることを特徴とする請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
プロセッサおよび少なくとも１つのメモリを有し、前記メモリが、請求項１〜１０にしたがう方法を前記プロセッサに実施させるプログラムコマンドを含んでいることを特徴とする携帯型データ記憶媒体。
【請求項１８】
請求項１１または請求項１２に記載の特徴を有する方法をコンピュータに実施させるプログラムコマンドを備えていることを特徴とするコンパイラ。
【請求項１】
プログラムの実行中に生成されるオブジェクトを格納するための第１および第２のメモリ領域を有する携帯型データ記憶媒体によって前記プログラムの実行中にメモリを管理する方法であって、前記第２のメモリ領域への書込み動作が前記第１のメモリ領域への書込み動作よりも高速に実施される方法であり、
プログラムの特定のメソッド実行の結果として生成されるオブジェクトの少なくとも一部を前記第２のメモリ領域に作成するステップと、
更なるプログラムの実行中に、前記オブジェクトへの永続的に格納されたリファレンスが生成されたかどうかを監視するステップ、
更なるプログラム実行中に、前記オブジェクトへの永続的に格納されたリファレンスが生成された場合に、前記オブジェクトを前記第１のメモリ領域に転送するステップと、
前記実行によりオブジェクトを作成した前記特定のメソッドの終了時に、第２のメモリ領域を解放するステップであって、少なくとも前記特定のメソッドが、解放されるべき第２のメモリ領域のメモリスペースに存在するオブジェクトへのリファレンスをリターンしないときに、前記第２のメモリ領域の占有状態を示す占有状態指標を前記特定のメソッドが呼び出された時点における占有状態にリセットすることで、前記第２のメモリ領域のメモリスペースを前記特定のメソッドが呼び出された時点のレベルまで解放するステップとを有することを特徴とする方法。
【請求項２】
前記永続的なリファレンスが生成されたどうかを監視するステップが、前記永続的に可能されたリファレンスが生成され、または修正されるたびに実行されることを特徴とする請求項１に記載の方法。
【請求項３】
オブジェクトを前記第２のメモリ領域に作成するときに、必要となるであろう前記オブジェクトの転送のための十分なスペースが第１のメモリ領域内で利用できるか否か確認することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記プログラムのインストール中に生成するオブジェクトを前記第１のメモリ領域に作成することを特徴とする請求項１〜３のいずれか１項に記載の方法。
【請求項５】
ソースプログラムからの前記プログラムの生成時にローカルオブジェクトと識別されたオブジェクトだけを、最初に前記第２のメモリ領域に作成することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記オブジェクトが、例外発生時に生成される例外オブジェクトであることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項７】
前記オブジェクトが、暗号化動作のために一時的に必要とされるオブジェクトであることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項８】
前記特定のメソッドが、受信データパケットを処理するためのプロセスメソッドであることを特徴とする請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記特定のメソッドが、データ記憶媒体の複数のプログラム間の変更時に呼び出される選択または選択解除メソッドとは異なるメソッドであることを特徴とする請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記占有状態指標のリセットによる第２のメモリ領域のメモリスペースの解放は、ガベージコレクションの処理とは異なることを特徴とする請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
コンパイラにより、ソースプログラムを、携帯型データ記憶媒体によって実行されるようになっているプログラムに変換する方法であって、前記データ記憶媒体が、前記プログラムの実行中に生成されるオブジェクトを格納するための第１および第２のメモリ領域を有し、前記第２のメモリ領域への書込み動作が前記第１のメモリ領域への書込み動作よりも高速に実施される方法において、
前記ソースプログラムの、前記オブジェクトの生成をもたらす部分の変換に際して、前記コンパイラが前記ソースプログラムの部分を解析し、前記オブジェクトへの永続的に格納されたリファレンスが、前記ソースプログラムの被変換部分に後続するプログラム実行の間に生成される否かを判断し、該判断の結果に応じて、前記コンパイラが、前記オブジェクトを前記第１のメモリ領域に作成するプログラムコードを生成するか、または前記オブジェクトの少なくとも一部を前記第２のメモリ領域に作成するプログラムコードを生成することを特徴とする方法。
【請求項１２】
生成された前記プログラムが前記携帯型データ記憶媒体によって実行されることで、請求項１〜１０のいずれか１項に係る方法が実行されるようになっていることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第２のメモリ領域に形成されるオブジェクトが、一時的にのみ必要とされるローカルオブジェクトであることを特徴とする請求項１〜１２のいずれか１項に記載の方法。
【請求項１４】
前記第２のメモリ領域が、ローカルヒープ形式のメモリ領域であることを特徴とする請求項１〜１３のいずれか１項に記載の方法。
【請求項１５】
前記第２のメモリ領域が、スタックメモリ内に配置されることを特徴とする請求項１から１４のいずれか１項に記載の方法。
【請求項１６】
前記データ記憶媒体が「Ｊａｖａ Ｃａｒｄ」であり、前記プログラムが「Ｊａｖａ Ｃａｒｄ」アプレットであることを特徴とする請求項１〜１５のいずれか１項に記載の方法。
【請求項１７】
プロセッサおよび少なくとも１つのメモリを有し、前記メモリが、請求項１〜１０にしたがう方法を前記プロセッサに実施させるプログラムコマンドを含んでいることを特徴とする携帯型データ記憶媒体。
【請求項１８】
請求項１１または請求項１２に記載の特徴を有する方法をコンピュータに実施させるプログラムコマンドを備えていることを特徴とするコンパイラ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−１６４３５０（Ｐ２０１２−１６４３５０Ａ）
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願番号】特願２０１２−１０５１３４（Ｐ２０１２−１０５１３４）
【出願日】平成２４年５月２日（２０１２．５．２）
【分割の表示】特願２００６−５０５３６９（Ｐ２００６−５０５３６９）の分割
【原出願日】平成１６年５月４日（２００４．５．４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５９６００７５１１）ギーゼッケ ウント デフリエント ゲーエムベーハー (47)
【氏名又は名称原語表記】Ｇｉｅｓｅｃｋｅ ＆ Ｄｅｖｒｉｅｎｔ ＧｍｂＨ
【Ｆターム（参考）】
【公開日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願日】平成２４年５月２日（２０１２．５．２）
【分割の表示】特願２００６−５０５３６９（Ｐ２００６−５０５３６９）の分割
【原出願日】平成１６年５月４日（２００４．５．４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５９６００７５１１）ギーゼッケ ウント デフリエント ゲーエムベーハー (47)
【氏名又は名称原語表記】Ｇｉｅｓｅｃｋｅ ＆ Ｄｅｖｒｉｅｎｔ ＧｍｂＨ
【Ｆターム（参考）】
[ Back to top ]