JP2006164294A - Ｊｉｔコンパイラを備えた仮想計算機 - Google Patents

Abstract

【課題】本発明はＪＩＴコンパイラを備えた仮想計算機に関し、限られたメモリ容量で処理の高速化を図り、応答性能の向上を図る。
【解決手段】仮想計算機のバイトコードをソフトウェアで解釈・実行する機能を有し、メモリ上に容量の制限されたネイティブコードの格納領域としてコードキャッシュを持ち、バイトコードを実行する際にバイトコードを仮想計算機が直接実行できるネイティブコードにコンパイルしてコードキャッシュ３に格納した後、そのネイティブコードを実行するＪＩＴコンパイラを備え、バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブル２を備えた。
【選択図】図３

Description

本発明は、携帯電話機や無線通信機能を有する携帯情報端末（ＰＤＡ）等の携帯型無線通信機器に利用可能なＪＩＴコンパイラを備えた仮想計算機に関する。

近年、インターネットの普及によりネットワークを介してプログラムを実行するシステムが実用化されている。特に、Ｊａｖａ言語は、携帯電話機上で「ｉ−ａＰＰｌｉ」としてプログラムを実行させることのできるものとして急速に広まってきている。

しかし、Ｊａｖａ言語は実行させるプラットホームを選ばない仮想計算機のプログラム（以下「バイトコード」と記す）として配付されるため、携帯型無線通信機器のプロセッサでは直接実行することができず、エミュレーション等の技術により実行を行っている。

本発明は、Ｊａｖａのような仮想計算機のバイトコードを携帯電話機、ＰＤＡ等に利用し、メモリが少ない携帯型無線通信機器上で高速に動作させることの可能なＪＩＴコンパイラを備えた仮想計算機に関する。

（従来例の説明）
以下、従来例について説明する。

(1) ：インタプリタの説明
図１２は、仮想計算機のコードであるバイトコードを解釈、実行するインタプリタの処理フローチャートである。以下、図１２に基づいて、インタプリタの処理を説明する。なお、Ｓ１〜Ｓ６は各処理ステップを示す。

従来、仮想計算機のバイトコードを実行する手段として、ソフトウェアによりバイトコードを逐次解釈、実行するインタプリタ方式が知られていた。しかし、このインタプリタ方式では、バイトコードの命令を１つずつ実行するため、処理速度が遅い。具体的には次の通りである。

先ず、バイトコードの命令フェッチを行い（Ｓ１）、フェッチした命令をデコードする（Ｓ２）。そして、デコードした結果が命令の実行であれば、その命令を実行し（Ｓ３、Ｓ４）、Ｓ１の処理へ移行する。また、デコードした結果が分岐であれば分岐処理を行い（Ｓ５）、Ｓ１の処理へ移行する。更に、デコードした結果がメソッド呼び出しであれば（Ｓ６）、メソッド呼び出しを行い（Ｓ６）、Ｓ１の処理へ移行する。以降、同様にして、命令毎に処理を行う。

(2) ：従来一般に使用されているＪＩＴコンパイラの説明
図１３は、インタプリタとＪＩＴコンパイラを組み合わせた時の処理フローチャートである。以下、図１３に基づき、インタプリタと、従来一般に使用されているＪＩＴコンパイラ（携帯電話機では使用されておらず、パーソナルコンピュータ等で使用されている）を組み合わせた時の処理を説明する。なお、Ｓ１１〜Ｓ２０は各処理ステップを示す。また、Ｓ１１〜Ｓ１６はインタプリタの処理であり、Ｓ１７〜Ｓ２０がＪＩＴコンパイラの処理である。

前記インタプリタの処理速度が遅いことを解決する方法として、ＪＩＴ（Just-IN-Compiler) コンパイラを使う手法が一般に使用されていた。このＪＩＴコンパイラはバイトコードをネイティブコードにコンパイルする。これにより、アプリケーションは直接そのマシンのプロセッサで実行できるようになり、高速な実行が可能になる。

一般に、ＪＩＴコンパイラは、ダウンロードしたクラス、又は実行を開始したメソッドという単位でコンパイルを行う。すなわち、メソッドのバイトコード全体をコンパイルする。また、コンパイルしたネイティブコードは、メモリ（プログラム上の格納領域）上に格納され、再び実行を行う時は再利用され、１度目の実行時には、コンパイルのオーバヘッドがあるが、２度目からはこのオーバヘッド無しに高速に実行できる。具体的には次のようになる。

先ず、バイトコードの命令フェッチを行い（Ｓ１１）、フェッチした命令をデコードする（Ｓ１２）。そして、デコードした結果が実行であれば、その命令を実行し（Ｓ１３、Ｓ１４）、Ｓ１１の処理へ移行する。また、デコードした結果が分岐であれば、分岐処理を行い（Ｓ１５）、Ｓ１１の処理へ移行する。更に、デコードした結果がメソッド呼び出しであれば、メソッド呼び出しを行い（Ｓ１６）、コンパイル済みか否かを判断する（Ｓ１７）。

その結果、コンパイル済みでなければ、コンパイルすべきか否かを判断し（Ｓ１８）、コンパイルすべきでなければ、Ｓ１１の処理へ移行するが、コンパイルすべきであれば、メソッドで呼び出したコードをＪＩＴコンパイラによりコンパイルしてネイティブコードを生成し、ネイティブコードの格納領域に格納し（Ｓ１９）、ネイティブコードを実行する（Ｓ２０）。ネイティブコードの実行中、メソッド呼び出しがあれば、Ｓ１６の処理へ移行し、メソッドの処理が終了すれば、Ｓ１１へ移行する。また、Ｓ１７の処理において、コンパイル済みであれば、Ｓ２０の処理へ移行する。以降、同様にして処理を行う。

なお、前記バイトコード（bytecode）とは、Ｊａｖａで開発したソフトのバイナリ表現形式として米サン・マイクロシステムズが定めたＪａｖａ仮想マシン（仮想計算機）のマシン・コードのことを言う。また、バイトコードをマシンが直接実行できるネイティブコードへ変換するソフトを「ＪＩＴ（Just-in-time）コンパイラ」と呼ぶ。

また、「メソッド」（Method）とは、オブジェクト指向プログラミングにおいて、オブジェクトの実行する操作の方法を記述したプログラム（サブルーチンと同じ意味）のことを言う。

前記のような従来のものにおいては、次のような課題があった。

すなわち、携帯電話機やＰＤＡ等の携帯型無線通信機器では使用できるメモリ容量が限られており、コンパイルしたコードを全てメモリ上に格納することはできない。また、前記携帯型無線通信機器でのソフトウェアの実行は、ゲームなどの対話型のアプリケーションが多く、応答性を高めるためには、コンパイルにあまり時間をかけることはできない。

特に、前記携帯型無線通信機器に搭載されたプロセッサでは処理能力が比較的低いため、大きなプログラムをコンパイルすると、実行中のプログラムが一瞬止まって見えることもある。また、一度しか実行されないようなバイトコードの場合、コンパイルする時間のオーバーヘッドのため、インタプリタで実行するよりも遅くなる。

本発明は、このような従来の課題を解決し、限られたメモリ容量で処理の高速化を図り、応答性能の向上を図ることを目的とする。

本発明は前記の目的を達成するため、次のように構成した。

(1) ：仮想計算機のバイトコードをソフトウェアで解釈・実行する機能を有し、メモリ上に、容量の制限されたネイティブコードの格納領域としてコードキャッシュを持ち、前記バイトコードを実行する際に、ＪＩＴコンパイラによりバイトコードを仮想計算機が直接実行できるネイティブコードにコンパイルして前記コードキャッシュに格納した後、そのネイティブコードを実行するＪＩＴコンパイラを備えた仮想計算機において、前記バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えていることを特徴とする。

(2) ：前記(1) の仮想計算機において、前記検索テーブル上、又は前記コードキャッシュ上に、命令の実行回数を計数するための実行カウンタを設け、バイトコードを実行する際に、前記実行カウンタの値を調べ、予め決めた特定回数より小さい場合はインタプリタで実行し、前記特定回数以上の場合は、ＪＩＴコンパイラによりバイトコードをコンパイルしてから実行する選択処理手段を備えていることを特徴とする。

(3) ：前記(1) の仮想計算機において、前記検索テーブルに、１度目の実行時にバイトコードのアドレスだけ登録し、ネイティブコードのアドレスの登録は特別な値、又は数字の０を登録にしておく検索テーブル情報登録手段と、１度目はインタプリタで実行し、２度目はＪＩＴコンパイルによりコンパイルして実行する実行制御手段を備えていることを特徴とする。

(4) ：前記(1) の仮想計算機において、コンパイル時間を短縮するために、コンパイルする範囲を制限し、処理の途中であっても、バイトコードの特定の命令を検出したら、そこまでをコンパイルして処理を中断する命令を生成し、残りはコンパイルしないように処理を制限する処理制限手段を備えていることを特徴とする。

(5) ：前記(1) の仮想計算機において、前記コードキャッシュに空きがなくなった時、コードキャッシュの先頭から順にネイティブコードを破棄する第１の破棄手段と、ＦＩＬＯ方式で最も昔にコンパイルしたコードから順に破棄する第２の破棄手段を備えていることを特徴とする。

（作用）
図１は本発明の原理説明図である。以下、図１を参照しながら本発明の作用を説明する。

(a) ：前記(1) では、バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えている。

従って、前記検索テーブルを検索することでコンパイルされているか否かを判断したり、コンパイルされている場合に、該当するネイティブコードの格納アドレスを検索することが容易になる。その結果、バイトコードをネイティブコードにコンパイルすることで、アプリケーションプログラムの実行時間を速くすることが可能になる。また、従来のＪＩＴコンパイラがネイティブコードを生成し格納するために使用するメモリが制限され、少ないメモリでも処理が高速化できる。

(b) ：前記(2) では、選択処理手段が、バイトコードを実行する際に、実行カウンタの値を調べ、予め決めた特定回数より小さい場合はインタプリタで実行し、前記特定回数以上の場合は、ＪＩＴコンパイラによりバイトコードをコンパイルしてから実行する。

この場合、コンパイル処理は時間を要するため、一度しか実行はないようなバイトコードはコンパイルして実行するよりもインタプリタで実行する方が速い。そこで、前記のように処理を行うことで、アプリケーションプログラムの全体の実行速度を速くすることができる。

(c) ：前記(3) では、検索テーブル情報登録手段は、検索テーブルに、１度目の実行時にバイトコードのアドレスだけ登録し、ネイティブコードのアドレスの登録は特別な値、又は数字の０を登録しておく。また、実行制御手段は、１度目はインタプリタで実行し、２度目はＪＩＴコンパイルによりコンパイルして実行するように制御する。

この場合、コンパイル処理は時間を要するため、一度しか実行はないようなバイトコードはコンパイルして実行するよりもインタプリタで実行する方が速い。そこで、前記のように処理を行うことで、アプリケーションプログラムの全体の実行速度を速くすることができる。また、前記(2) と比較して、実行カウンタのための領域が必要なく、メモリを節約できる。

(d) ：前記(4) では、処理制限手段は、コンパイル時間を短縮するために、コンパイルする範囲を制限し、処理の途中であっても、バイトコードの特定の命令を検出したら、そこまでをコンパイルして処理を中断する命令を生成し、残りはコンパイルしないように処理を制限する。

この場合、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分もコンパイルしていた。これに対して本発明の前記(4) では、必ず実行する部分だけをコンパイルするので、コンパイルに消費する時間の無駄がなく高速である。

また、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分のネイティブコードも生成していた。しかし、本発明の前記(4) では、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(e) ：前記(5) では、第１の破棄手段は、コードキャッシュに空きがなくなった時、コードキャッシュの先頭から順にネイティブコードを破棄する。そして、第２の破棄手段は、ＦＩＬＯ方式で最も昔にコンパイルしたコードから順に破棄する。

このようにすれば、ネイティブコードの破棄の方式が簡単なため、実現し易く、ネイティブコードの断片化が起きない。

(1) ：バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えている。

従って、前記検索テーブルを検索することでコンパイルされているか否かを判断したり、コンパイルされている場合に、該当するネイティブコードの格納アドレスを検索することが容易になる。その結果、バイトコードをネイティブコードにコンパイルすることで、アプリケーションプログラムの実行時間を速くすることが可能になる。また、従来のＪＩＴコンパイラがネイティブコードを生成し、格納するために使用するメモリが制限され、少ないメモリでも処理が高速化できる。

(2) ：選択処理手段がバイトコードを実行する際に、実行カウンタの値を調べ、予め決めた特定回数より小さい場合はインタプリタで実行し、前記特定回数以上の場合は、ＪＩＴコンパイラによりバイトコードをコンパイルしてから実行する。

この場合、コンパイル処理は時間を要するため、一度しか実行はないようなバイトコードはコンパイルして実行するよりもインタプリタで実行する方が速い。そこで、前記のように処理を行うことで、アプリケーションプログラムの全体の実行速度を速くすることができる。

(3) ：検索テーブル情報登録手段は、検索テーブルに、１度目の実行時にバイトコードのアドレスだけ登録し、ネイティブコードのアドレスの登録は特別な値、又は数字の０を登録にしておく。また、実行制御手段は、１度目はインタプリタで実行し、２度目はＪＩＴコンパイルによりコンパイルして実行するように制御する。

この場合、コンパイル処理は時間を要するため、一度しか実行しないようなバイトコードはコンパイルして実行するよりもインタプリタで実行する方が速い。そこで、前記のように処理を行うことで、アプリケーションプログラムの全体の実行速度を速くすることができる。また、前記(2) と比較して、実行カウンタのための領域が必要なく、メモリを節約できる。

(4) ：処理制限手段は、コンパイル時間を短縮するために、コンパイルする範囲を制限し、処理の途中であっても、バイトコードの特定の命令を検出したら、そこまでをコンパイルして処理を中断する命令を生成し、残りはコンパイルしないように処理を制限する。

この場合、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分もコンパイルしていた。これに対して請求項４では、必ず実行する部分だけをコンパイルするので、コンパイルに消費する時間の無駄がなく高速である。

また、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分のネイティブコードも生成していた。しかし、請求項４では、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(5) ：第１の破棄手段は、コードキャッシュに空きがなくなった時、コードキャッシュの先頭から順にネイティブコードを破棄する。そして、第２の破棄手段は、ＦＩＬＯ方式で最も昔にコンパイルしたコードから順に破棄する。このようにすれば、ネイティブコードの破棄の方式が簡単なため、実現し易く、ネイティブコードの断片化が起きない。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、以下に説明する仮想計算機は、プログラム上だけで実現される仮想的な計算機であり、前記携帯型無線通信機器内のメモリに格納されたプログラムを、内部のプロセッサ（ＣＰＵ、又はＭＰＵ）が実行することで実現される仮想マシンである。

従って、以下に説明するフローチャートで表現された処理は、全て前記プログラム上で実行されるものである。そのため、仮想計算機上のメモリ、コードキャッシュ、検索テーブル等は、全て前記プログラム上で実現されるものである。

(1) ：例１の詳細な説明
(a) ：例１の内容
例１は、仮想計算機のバイトコードをソフトウェアで解釈・実行する機能を有し、メモリ上に、容量の制限されたネイティブコードの格納領域としてコードキャッシュを持ち、バイトコードを実行する際に、ＪＩＴコンパイラによりバイトコードを仮想計算機が直接実行できるネイティブコードにコンパイルしてコードキャッシュに格納した後、そのネイティブコードを実行するＪＩＴコンパイラ（以下、単に「コンパイラ」とも記す）を備えた仮想計算機に関するものであり、バイトコードのアドレスから、コンパイルされているか否かを判断するための情報（後述する）と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えている。

そして、コンパイルを行う時にネイティブコードの格納領域に空きがなければ、既に格納済みのコンパイルコードを破棄して前記格納領域に空き領域を作り、検索テーブルを更新するものである。

(b) ：フローチャートによる処理（その１）の説明
図１は例１の処理フローチャート（その１）である。以下、図１に基づいて、例１の処理（その１）を説明する。なお、Ｓ３１〜Ｓ４０は各処理ステップを示す。この処理では、全てのバイトコードを対象としてコンパイルされているかどうかをチェックする例であり、仮想計算機上の処理である。

先ず、全てのバイトコードに対して、検索テーブル上のタグ（ｔａｇ）情報を利用して（詳細は後述する）コンパイル済みか否かを判断し（Ｓ３１）、コンパイル済みでなければ、コンパイルすべきか否かを判断し（Ｓ３２）、コンパイルすべきでないと判断した場合には、バイトコード命令のフェッチを行い（Ｓ３３）、フェッチされた命令のデコードを行う（Ｓ３４）。

その結果、実行であれば（Ｓ３５、Ｓ３６）その命令を実行し、Ｓ３１の処理へ移行する。また、分岐であれば（Ｓ３７）分岐処理を行い、Ｓ３１の処理へ移行する。更に、メソッド呼び出しであれば（Ｓ３８）、メソッド呼び出しを行い、Ｓ３１の処理へ移行する。

また、前記Ｓ３２の処理で、コンパイルすべきであると判断した場合には、部分的にコンパイルし、ネイティブコードを生成してネイティブコード格納領域へ格納し（Ｓ３９）、ネイティブコードを実行し（Ｓ４０）、Ｓ３１の処理へ移行する。また、Ｓ３１の処理で、コンパイル済みであれば、Ｓ４０の処理へ移行する。前記処理において、Ｓ３１〜Ｓ３８はインタプリタの処理であり、Ｓ３９、Ｓ４０がＪＩＴコンパイラによる処理である。

(c) ：フローチャートによる処理（その２）の説明
図２は例１の処理フローチャート（その２）である。以下、図２に基づいて、例１の処理（その２）を説明する。なお、Ｓ４１〜Ｓ５０は各処理ステップを示す。

この処理では、分岐、メソッド呼び出しなどの実行制御が途切れる地点で、コンパイルのチェックを行う。一般のＪＩＴコンパイラとの違いとしては、コンパイルをメソッド単位で行わず、以下に説明する例５、例６、例７、例８等の条件で、コンパイルを中断することが特徴である。

先ず、バイトコード命令のフェッチを行い（Ｓ４１）、命令デコードを行う（Ｓ４２）。その結果、実行であれば（Ｓ４３、Ｓ４４）、その命令を実行し、Ｓ４１の処理へ移行する。また、分岐であれば（Ｓ４５）、分岐処理を行い（Ｓ４５）、メソッド呼び出しであれば（Ｓ４６）メソッド呼び出しを行う。

そして、分岐又はメソッド呼び出しを行った場合、コンパイル済みか否かを判断し（Ｓ４７）、コンパイル済みでなければ、コンパイルすべきか否かを判断する（Ｓ４８）。その結果、コンパイルすべきでないと判断した場合には、Ｓ４１の処理へ移行する。

また、コンパイルすべきであると判断した場合は、途中までコンパイルを行い、ネイティブコードを生成しネイティブコード格納領域へ格納する（Ｓ４９）。そして、ネイティブコードを実行し（Ｓ５０）、Ｓ４７の処理、又はＳ４６の処理へ移行する。

(d) ：検索テーブルの説明
図３は例１の検索テーブル例である。前記のようにコンパイル済みか否かを調べて判断するために、検索テーブルを使用するが、その検索テーブルの１例を図３に示す。図３において、１はコンパレータ、２は検索テーブル、３はコードキャッシュである。

この検索テーブル２は、タグ（ｔａｇ）と、ネイティブコードのアドレス（コードキャッシュ３内のネイティブコード領域のアドレス）との対応情報が登録できるようになっており、ネイティブコードのアドレスからコードキャッシュ３のネイティブコード領域のデータが検索できるようになっている。

また、検索テーブル２は、バイトコードアドレス（上位Ｍビット＋下位Ｎビットとする）の下位Ｎビットを利用してタグ（ｔａｇ）を検索することで、ネイティブコードのアドレスが検索できるようになっている。そして、バイトコードアドレスの上位Ｍビットをコンパレータ１に入力すると共に、検索テーブルのタグ（ｔａｇ）情報をコンパレータ１に入力し、両者が一致するか否かの比較を自動的に行うようになっている。

前記比較の結果、両者が一致（ｈｉｔ）した場合、コンパレータ１から一致出力が出され、この一致出力信号によりコンパイル済みと判断できるようになっている。

(e) ：例１の特徴
前記図３の検索テーブルを検索することでコンパイルされているか否かを判断したり、コンパイルされている場合に、該当するネイティブコードの格納アドレス（コードキャッシュ３内のネイティブコード領域のアドレス）を検索することが容易になる。

その結果、バイトコードをネイティブコードにコンパイルすることで、アプリケーションプログラムの実行時間を速くすることが可能になる。また、従来のＪＩＴコンパイラがネイティブコードを生成し、格納するために使用するメモリが制限され、少ないメモリ容量でも処理が高速化できる。

(2) ：例２の詳細な説明
(a) ：例２の内容
例２は、例１において、検索テーブル２上、又はコードキャッシュ３上に命令の実行回数を計数する実行カウンタを設け、仮想計算機のコードであるバイトコードを実行する際に、実行カウンタの値が、予め決めた特定回数より小さければインタプリタで実行し、前記特定回数より大きく、頻繁に実行されるバイトコードはＪＩＴコンパイラによりコンパイルして実行する例である。

(b) ：検索テーブルの説明
図４は例２の検索テーブル例である。図４に示したように、検索テーブル２は、タグ（ｔａｇ）と、実行カウンタと、ネイティブコードのアドレスを対応させた情報が格納されており、ネイティブコードのアドレスから、コードキャッシュ３のネイティブコード領域のアドレスが検索できるようになっている。

また、検索テーブル２は、バイトコードアドレス（上位Ｍビット＋下位Ｎビットとする）の下位Ｎビットを利用してタグ（ｔａｇ）を検索することで、ネイティブコードアドレスが検索できるようになっている。そして、バイトコードアドレスの上位Ｍビットをコンパレータ１に入力すると共に、検索テーブルのタグ（ｔａｇ）情報をコンパレータ１に入力し、両者が一致する（ｈｉｔ）か否かの比較を行う。

前記比較の結果、両者が一致（ｈｉｔ）した場合、コンパレータ１から一致出力が出され、この一致出力信号によりコンパイル済みと判断する。このような検索テーブルを利用し、バイトコードを実行する際に実行カウンタの値が特定回数より小さければインタプリタ（従来の処理）で実行し、特定回数より大きく頻繁に実行されるバイトコードはコンパイルして実行する。なお、前記実行カウンタは、コードキャッシュ３に設けても良い。

(c) ：フローチャートによる処理の説明
図５は、例２のコンパイル選択処理フローチャートである。以下、図５に基づいて、例２のコンパイルの選択処理を説明する。なお、Ｓ６１〜Ｓ７５は各処理ステップを示す。

この処理は、インタプリタの処理（Ｓ６１〜Ｓ６７）と、ＪＩＴコンパイラによるコンパイラの処理（Ｓ７１〜Ｓ７５）とに分かれている。インタプリタの処理では、コンパイル済みか否かを判断し（Ｓ６１）、コンパイル済みでなければ、テーブル登録済み（図４の検索テーブル２のｔａｇに登録されているか否か）を判断する（Ｓ６２）。その結果、テーブル登録済みでなければ、タグ（ｔａｇ）にアドレス登録を行い（Ｓ６３）、実行カウンタをクリアする（Ｓ６４）。次に、命令フェッチを行い（Ｓ６５）、デコードを行って（Ｓ６６）、実行する（Ｓ６７）。そして、Ｓ６１の処理に移行する。

Ｓ６２の処理でテーブル登録済みであると判断した場合には、検索テーブル２の実行カウンタをＵＰ（＋１）し（Ｓ７１）、予め決めた特定回数より大きいか否かを判断する（Ｓ７２）。その結果、特定回数より小さければ、Ｓ６５に移行しインタプリタで実行し、特定回数以上の場合は、Ｓ７３に移行してＪＩＴコンパイラによりバイトコードをコンパイルしてネイティブコードを生成し、コードキャッシュ３に登録する。また、この時、検索テーブル２にも必要な情報（ネイティブコードのアドレス）を登録する（Ｓ７４）。

次に、前記ネイティブコードを実行し（Ｓ７５）、Ｓ６１へ移行する。また、Ｓ６１の処理でコンパイル済みであると判断した場合には、Ｓ７５へ移行する。

(d) ：例２の特徴
コンパイル処理は時間を要するため、あまり実行されないバイトコードはコンパイルして実行するよりも、インタプリタで実行する方が、全体の処理速度が上がる。

(3) ：例３の詳細な説明
(a) ：例３の内容
例３は、例２のような実行カウンタを使用しないでコンパイルの選択を行う例であり、例１の処理において、検索テーブルに１度目の実行時にはバイトコードアドレスだけを登録（検索テーブル２のｔａｇに登録）し、ネイティブコードのアドレスの登録は特別なコンパイルの処理を行う関数（コンパイル又は処理の先頭アドレス）、又は数字の０にしておき、１度目はインタプリタで実行し、２度目はコンパイルして実行する例である。

(b) ：フローチャートによる処理の説明
図６は、例３のコンパイル選択処理フローチャートである。以下、図６に基づいて、例３のコンパイルの選択処理を説明する。なお、Ｓ８１〜Ｓ９４は各処理ステップを示す。

この処理は、インタプリタの処理（Ｓ８１〜Ｓ８６）と、コンパイラの処理（Ｓ９１〜Ｓ９４）とに分かれている。インタプリタの処理では、先ず、Ａから始まりテーブル登録済み（検索テーブル２に登録されている）か否かを判断し（Ｓ８１）、登録済みでなければ（１度目）、インタプリタによる処理を行う。この場合、検索テーブル２のタグ（ｔａｇ）にバイトコードアドレス（バイトコードのアドレスのみ）を登録する（Ｓ８２）。

次に、ネイティブコードアドレスに、エントリＢを登録して（Ｓ８３）、命令フェッチを行い（Ｓ８４）、デコードを行う（Ｓ８５）。そして、デコードした命令を実行し（Ｓ８６）、Ｓ８１の処理へ移行する。

また、Ｓ８１の処理で、テーブル登録済みであると判断した場合（２度目）は、ＪＩＴコンパイラによる処理を行う。この場合、ネイティブコードアドレスへジャンプし（Ｓ９１）、エントリＢからＪＩＴコンパイラによるコンパイルを行い（Ｓ９２）、ネイティブコードアドレス登録を行う（Ｓ９３）。そして、ネイティブコードを実行し（Ｓ９４）、Ｓ８１の処理へ移行する。

また、前記Ｓ９１の処理結果により、Ｓ９４に移行してネイティブコードを実行し（Ｓ９４）、Ｓ８１の処理へ移行する。

(c) ：例３の特徴
コンパイル処理は時間を要するため、一度しか実行はないようなバイトコードはコンパイルして実行するよりもインタプリタで実行する方が速い。そこで、前記のように処理を行うことで、アプリケーションプログラムの全体の実行速度を速くすることができる。また、前記例２と比較して、実行カウンタのための領域が必要なく、メモリを節約できる。

(4) ：例４の詳細な説明
(a) ：例４の内容
例４は、例１において、検索テーブルはコンパイルされているかどうかだけの情報（タグの情報）を持ち、ネイティブコードのアドレスはバイトコードのアドレスから計算する例である。

(b) ：検索テーブルとコードキャッシュの構成例
図７は例４の検索テーブルとコードキャッシュの構成例である。この検索テーブル２には、タグ（ｔａｇ）のみ格納されている。この場合、バイトコードアドレスの下位Ｎビットを利用して検索テーブル２をアクセスすると共に、前記Ｎビットの下位アドレスを演算器４により整数倍、例えば、８倍（×８）した値によりコードキャッシュ３のネイティブコード領域のアドレスへアクセスできるようになっている。

また、検索テーブル２は、バイトコードアドレス（上位Ｍビット＋下位Ｎビットとする）の下位Ｎビットを利用してタグ（ｔａｇ）を検索できるようになっている。そして、バイトコードアドレスの上位Ｍビットをコンパレータ１に入力すると共に、検索テーブルのタグ（ｔａｇ）情報をコンパレータ１に入力し、両者が一致するか否かの比較を行う。前記比較の結果、両者が一致した場合、コンパレータ１から一致出力が出されるが、この一致出力信号によりコンパイル済みと判断する。

(c) ：例４の特徴
バイトコードのアドレスに対し、コンパイルされるネイティブコードのメモリ上の位置が一意に決まるため、テーブルからネイティブコードのアドレスを索引する必要がなくなる。また、置換の際には、破棄すべきネイティブコードを探す必要がなく単純に処理できる。

(5) ：例５の詳細な説明
(a) ：例５の内容
例５は、例１において、コンパイル時間を短縮（応答性を向上）するために、コンパイルする範囲を制限する。処理の途中であっても、バイトコードの特定の命令（分岐命令、メソッド呼び出しなど）を検出したら、そこまでをコンパイルし、処理を中断する命令（ネイティブコードの分岐命令や割り込み命令）を生成し（ネイティブコードの最終コードの後に、分岐命令や割り込み命令を生成し）、残りはコンパイルしない例である。

すなわち、仮想計算機において、コンパイル時間を短縮するために、コンパイルする範囲を制限し、処理の途中であっても、バイトコードの特定の命令を検出したら、そこまでをコンパイルして処理を中断する命令を生成し、残りはコンパイルしないように処理を制限する処理制限手段を備えている。

(b) ：例５の特徴
必ず実行する部分だけがコンパイルされ効率が良い。例えば、“ＩＦ条件ＴＨＥＮ処理”のようなバイトコードの列をコンパイルするとき、「条件」を処理する部分だけコンパイルを行い、「処理」の部分はコンパイルしない。

この場合、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分もコンパイルしていた。これに対して例５では、必ず実行する部分だけをコンパイルするので、コンパイルに消費する時間の無駄がなく高速である。

また、従来は、メソッド全体をコンパイルしていたので、全く実行しない部分のネイティブコードも生成していた。しかし、例５では、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(6) ：例６の詳細な説明
(a) ：例６の内容
例６は、コンパイル時間の短縮を行う例であり、例５において、特定な命令の検出のほかに、バイトコードの量でコンパイルを中断する。例えば、１００命令コンパイルしたところでコンパイルを中断する例である。なお、例６は、例４と同様に、例１の処理におけるコンパイルを中断させる条件を提供するものである。

(b) ：例６の特徴
例５と同じように、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(7) ：例７の詳細な説明
(a) ：例７の内容
例７はコンパイル時間の短縮を行う例であり、例５において、特定な命令の検出のほかに、生成したネイティブコードの量でコンパイルを中断する。例えば、コンパイルが１２８ワード分だけネイティブコードを生成したら、コンパイルを中断する。なお、例７は、例４と同様に、例１の処理におけるコンパイルを中断させる条件を提供するものである。

(b) ：例７の特徴
例５と同じように、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(8) ：例８の詳細な説明
(a) ：例８の内容
例８はコンパイル時間の短縮を行う例であり、特定な命令の検出のほかに、時間によってコンパイルを中断する。例えば、コンパイラがコンパイルの処理に１００ミリセカンド消費したら、コンパイルを中断する。なお、例８は、例４と同様に、例１の処理におけるコンパイルを中断させる条件を提供するものである。

(b) ：例８の特徴
例５と同じように、必ず実行する部分だけをコンパイルするので、生成するネイティブコードに無駄がなく、メモリの消費が抑えられる。また、アプリケーションプログラムの応答性を向上させることができる。すなわち、コンパイルしている最中はアプリケーションプログラムの実行は停止するので、この停止している時間が短縮する。

(9) ：例９の詳細な説明
(a) ：例９の内容
例９は、コードキャッシュの置換を行う例であり、例１において、コードキャッシュに空きがなくなったとき、コードキャッシュの先頭から順にネイティブコードを破棄する。この処理では、ＦＩＬＯ（First In Last Out ）方式で最も昔にコンパイルしたコードから順に破棄する。

(b) ：コードキャッシュの置換の説明
図８は例９のコードキャッシュの置換処理説明図である。この例では、初期値として、Ｐ１：命令生成ポインタはコードキャッシュの先頭、Ｐ２：解放ポインタはコードキャッシュの末尾を指しておく。実行が進む（コンパイルが何度も行われる）につれて、コードキャッシュ３は小さなブロックに分けられ、ブロックの先頭にタグ（ｔａｇ）ポインタ（検索テーブルへのポインタ）と、ネクスト（ｎｅｘｔ）ポインタ（次のブロックを指すポインタ）が格納される。

ブロックの残り部分はネイティブコードを格納する命令領域である。ネクスト（ｎｅｘｔ）ポインタはポインタである必要はなく、ブロックの切れ目が判れば良い。

(c) ：フローチャートによる処理の説明
図９は、例９のコードキャッシュ置換処理フローチャートである。以下、図９に基づいて、例９の処理を説明する。なお、Ｓ１０１〜Ｓ１１１は各処理ステップを示す。

この処理は、コンパイルの処理の最中にコードキャッシュ３の置換処理を行う例である。先ず、生成する領域のタグ（ｔａｇ）ポインタに検索テーブル２へのタグ（ｔａｇ）ポインタを設定する（Ｓ１０１）。設定する領域は図８のＰ１（命令生成ポインタ）によって指示される。Ｓ１０２、Ｓ１０３、Ｓ１０４、Ｓ１０５がコンパイル処理のメインループであり、バイトコードからネイティブコードを生成する処理である。

次に、ＪＩＴコンパイルのコンパイル処理により、バイトコードからネイティブコードへの変換を行う（Ｓ１０２）。変換後のネイティブコードをコードキャッシュ３に格納する前に、命令生成ポインタと解放ポインタの値を比較（命令生成ポインタ＜解放ポインタの条件を満たしているか否かを比較）する（Ｓ１０３）ことで、有効なコードを上書きしてしまわないかチェックする。

その結果、命令生成ポインタが解放ポインタより小さければ、全て解放済みの領域なので、コードキャッシュ３にネイティブコードを生成して書き込む（Ｓ１０４）。この時、命令生成ポインタを進める。次に、コンパイル終了条件を満たしたか否かを判断する（Ｓ１０５）。

その結果、コンパイル終了条件を満たさなければ、Ｓ１０２の処理へ移行し、コンパイル処理を継続する。また、コンパイル終了条件を満たしたら、生成したネイティブコードを１つのブロックとして構成する。この場合、生成した領域のネクストポインタに、命令生成ポインタの値を設定する（Ｓ１０６）。

また、Ｓ１０３の処理で、前記条件を満たしていない場合、すなわち、命令生成ポインタが解放ポインタと等しいか、又は大きい場合、有効なブロックを解放する必要がある。そこで、解放ポインタがコードキャッシュの最後を指している（解放ポインタ＜コードキャッシュの末尾の条件を満たしている）か否かをチェックする（Ｓ１０７）。

その結果、解放ポインタがコードキャッシュの最後を指している場合は、解放ポインタをコードキャッシュ３の先頭に設定し（Ｓ１０８）、命令生成ポインタをコードキャッシュ３の先頭のブロックの命令領域に設定する（Ｓ１０９）。この処理により、コードキャッシュ３の先頭に戻ってブロックの解放を行う。

次に、解放ポインタが示すタグ（ｔａｇ）ポインタから検索テーブル２のタグ（ｔａｇ）をクリアする（Ｓ１１０）。そして、前記Ｓ１１０の処理により、検索テーブルのタグ（ｔａｇ）が無効化され、解放ポインタが示すブロックが実際に解放される。次に、解放ポインタを次のポインタ（ｎｅｘｔポインタ）に設定して（Ｓ１１１）、Ｓ１０４の処理へ移行する。この処理で、解放ポインタが次のブロックを指すようになる。

(d) ：特徴
コードキャッシュから検索テーブルへのポインタを持つことによって、キャッシュブロックのサイズを可変長にでき、メモリを有効に活用することが可能になる。このポインタがない場合でも、検索テーブル全体を調べてキャッシュを無効化することができるが、検索テーブル全体を調べるのは処理量が多く、コンパイルに時間を浪費するが、例９の処理により、キャッシュの無効化を高速に行うことができる。

(10)：例１０の詳細な説明
(a) ：例１０の内容
図１０は例１０のコードキャッシュの置換処理説明図である。例１０は、コードキャッシュの置換を行う例であり、コードキャッシュ３に空きがなくなったとき、検索テーブル２の実行カウンタを値の小さいものをスキャンし、実行カウンタの値の小さなものから順に破棄する。実行カウンタはコンパイル直後は適当な大きな値を設定しておき、実行する度に実行したコードに対応するカウンタを増加するようにし、置換が必要となったときに、全体のカウンタを減少するようにする。

(b) ：フローチャートによる処理の説明
図１１は例１０の処理フローチャートである。以下、図１１に基づいて例１０の処理を説明する。なお、Ｓ１２１〜Ｓ１３６は各処理ステップを示す。また、Ｓ１２１〜Ｓ１３１の処理は、図５に示した例２のＳ６１〜Ｓ７５の処理と同じである。

インタプリタの処理では、コンパイル済みか否かを判断し（Ｓ１２１）、コンパイル済みでなければ、テーブル登録済み（図４の検索テーブル２のｔａｇに登録されているか否か）を判断する（Ｓ１２２）。その結果、テーブル登録済みでなければ、タグ（ｔａｇ）にアドレス登録を行い（Ｓ１２３）、実行カウンタをクリアする（Ｓ１２４）。

次に、命令フェッチを行い（Ｓ１２５）、デコードを行って（Ｓ１２６）、前記処理と同様にして命令を実行する（Ｓ１２７）。そして、Ｓ１２１の処理に移行する。

また、前記Ｓ１２２の処理でテーブル登録済みであると判断した場合には、検索テーブル２の実行カウンタをＵＰ（＋１）し（Ｓ１２９）、予め決めた特定回数より大きいか否かを判断する（Ｓ１３０）。その結果、特定回数より小さければ、Ｓ１２５に移行しインタプリタで実行し、特定回数以上の場合は、ＪＩＴコンパイラによりバイトコードをコンパイルしてネイティブコードを生成し（Ｓ１３１）、生成したネイティブコードをコードキャッシュ３に登録する（Ｓ１３２）。

また、この時、検索テーブル２の実行カウンタを設定する。次に、前記Ｓ１３２の処理で登録したネイティブコードを実行し（Ｓ１３３）、Ｓ１２１の処理へ移行する。また、Ｓ１２１の処理で、コンパイル済みであると判断した場合は、検索テーブル２の実行カウンタをＵＰ（＋１）して（Ｓ１２８）、Ｓ１３３の処理へ移行する。

一方、前記Ｓ１３１の処理において、ネイティブコードを生成した場合、コードキャッシュ３に空きがあるか否かを判断し（Ｓ１３４）、空きがあれば、Ｓ１３１の処理へ戻る。しかし、コードキャッシュ３に空きがなければ、実行カウンタ全体をスキャンし、個々の実行カウンタを減少させる（Ｓ１３５）。そして、実行回数が少ないエントリを破棄して、コードキャッシュ３に空きを作成し（Ｓ１３６）、Ｓ１３１の処理に戻る。

(c) ：例１０の特徴
頻繁に実行されるネイティブコードが破棄されにくくなる。しかし、空き領域が断片化し、ネイティブコード上で断片化した箇所への無駄な分岐命令が必要となる。

(11)：例１１の詳細な説明
(a) ：例１１の内容
例１１は、コードキャッシュ３のコンパクションの例であり、例１０において、コードキャッシュ３の空き領域の断片化が起きる。この時に、ネイティブコードのかたまりを移動（リロケーション）することで、コンパイラが一度に生成するコードを一塊にまとめる。

(b) ：例１１の特徴
断片化により分断された命令の間に無駄な分岐命令を挿入する必要がなくなる。実行する命令列がコードキャッシュ上に分断されることがなくなり、一塊となるため、命令キャッシュが効率的に使われ、性能が向上する。

(12)：例１２の詳細な説明
(a) ：例１２の内容
例１２は、検索テーブルのヒット率の向上を図る例であり、例５において、コンパイルした全てのバイトコードの命令を検索テーブルに登録せず、コンパイルした命令シーケンスの先頭だけ検索テーブルに登録する。

(b) ：例１２の特徴
検索テーブルのエントリ数にも制限があり、コンパイルした全てのバイトコード命令のアドレスを登録すると、検索テーブル２を上書きする機会が増えるため、コンパイル済みにもかかわらず、検索ミスする率が大きくなり、無駄なコンパイルを行う。これを防ぐため、コンパイルした命令シーケンスの先頭だけを登録する。

前記の説明に対し、次の構成を付記する。

（付記１）
仮想計算機のバイトコードをソフトウェアで解釈・実行する機能を有し、メモリ上に、容量の制限されたネイティブコードの格納領域としてコードキャッシュを持ち、
前記バイトコードを実行する際に、ＪＩＴコンパイラによりバイトコードを仮想計算機が直接実行できるネイティブコードにコンパイルして前記コードキャッシュに格納した後、そのネイティブコードを実行するＪＩＴコンパイラを備えた仮想計算機において、
前記バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えていることを特徴とするＪＩＴコンパイラを備えた仮想計算機。

（付記２）
前記検索テーブル上、又は前記コードキャッシュ上に、命令の実行回数を計数するための実行カウンタを設け、
前記バイトコードを実行する際に、実行カウンタの値を調べ、予め決めた特定回数より小さい場合はインタプリタで実行し、
前記特定回数以上の場合は、ＪＩＴコンパイラによりバイトコードをコンパイルしてから実行する選択処理手段を備えていることを特徴とする（付記１）記載のＪＩＴコンパイラを備えた仮想計算機。

（付記３）
前記検索テーブルに、１度目の実行時にバイトコードのアドレスだけ登録し、ネイティブコードのアドレスの登録は特別な値、又は数字の０にしておく検索テーブル情報登録手段と、
１度目はインタプリタで実行し、２度目はＪＩＴコンパイルによりコンパイルして実行する実行制御手段を備えていることを特徴とする（付記１）記載のＪＩＴコンパイラを備えた仮想計算機。

（付記４）
前記検索テーブルは、コンパイルされているかどうかを判断するだけの情報を持ち、ネイティブコードのアドレスは、バイトコードのアドレスから計算して求める演算手段を備えていることを特徴とする（付記１）記載の仮想計算機。

（付記５）
コンパイル時間を短縮するために、コンパイルする範囲を制限し、処理の途中であっても、バイトコードの特定の命令を検出したら、そこまでをコンパイルし、処理を中断する命令を生成し、残りはコンパイルしないように処理を制限する処理制限手段を備えていることを特徴とする（付記１）記載のＪＩＴコンパイラを備えた仮想計算機。

（付記６）
処理制限手段は、特定な命令の検出の他に、バイトコードの量でコンパイルを中断することを特徴とする（付記５）記載の仮想計算機。

（付記７）
処理制限手段は、特定な命令の検出の他に、生成したネイティブコードの量でコンパイルを中断することを特徴とする（付記５）記載の仮想計算機。

（付記８）
処理制限手段は、特定な命令の検出の他に、時間によってコンパイルを中断することを特徴とする（付記５）記載の仮想計算機。

（付記９）
前記コードキャッシュに空きがなくなった時、コードキャッシュの先頭から順にネイティブコードを破棄する第１の破棄手段と、
ＦＩＬＯ方式で最も昔にコンパイルしたコードから順に破棄する第２の破棄手段を備えていることを特徴とする（付記１）記載のＪＩＴコンパイラを備えた仮想計算機。

本発明の実施の形態における例１の処理フローチャート（その１）である。 本発明の実施の形態における例１の処理フローチャート（その２）である。 本発明の実施の形態における例１の検索テーブル例である。 本発明の実施の形態における例２の検索テーブル例である。 本発明の実施の形態における例２のコンパイル選択処理フローチャートである。 本発明の実施の形態における例３のコンパイル選択処理フローチャートである。 本発明の実施の形態における例４の検索テーブルとコードキャッシュの構成例である。 本発明の実施の形態における例９のコードキャッシュの置換処理説明図である。 本発明の実施の形態における例９のコードキャッシュの置換処理フローチャートである。 本発明の実施の形態における例１０のコードキャッシュの置換処理説明図である。 本発明の実施の形態における例１０の処理フローチャートである。 従来のインタプリタの処理フローチャートである。 従来のインタプリタとＪＩＴコンパイラを組み合わせた時の処理フローチャートである。

符号の説明

１ コンパイラ
２ 検索テーブル
３ コードキャッシュ
４ 演算器

Claims (1)

1. 仮想計算機のバイトコードをソフトウェアで解釈・実行する機能を有し、メモリ上に、容量の制限されたネイティブコードの格納領域としてコードキャッシュを持ち、
   前記バイトコードを実行する際に、ＪＩＴコンパイラによりバイトコードを仮想計算機が直接実行できるネイティブコードにコンパイルして前記コードキャッシュに格納した後、そのネイティブコードを実行するＪＩＴコンパイラを備えた仮想計算機において、
   前記バイトコードのアドレスから、コンパイルされているか否かを判断するための情報と、コンパイルされたネイティブコードのアドレスを検索する検索テーブルを備えると共に、
   前記コードキャッシュに空きがなくなった時、コードキャッシュの先頭から順にネイティブコードを破棄する第１の破棄手段と、
   ＦＩＬＯ方式で最も昔にコンパイルしたコードから順に破棄する第２の破棄手段を備えていることを特徴とするＪＩＴコンパイラを備えた仮想計算機。

Images