JP6379654B2 - 処理実行プログラム、処理実行方法、及び情報処理装置 - Google Patents

Description

本願は、処理実行プログラム、処理実行方法、及び情報処理装置に関する。

様々なモノがセンサを備えると共にインターネット等の通信ネットワークに接続して情報交換するＩｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓにより、モノを識別したり、モノの状況を把握したり、モノを制御したりすることが可能になってきている。その中でもモノと連携するアプリケーション（以下、「アプリ」と略称する）やサービスの開発にＷｅｂ技術を使うＷｅｂ ｏｆ Ｔｈｉｎｇｓが注目されている。Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）では、ユースケースや要求事項の検討及びその実現方向について議論されている。これは、Ｗｅｂ技術を扱える技術者が非常に多く、アプリやサービスの開発が促進され、その結果、ユーザは様々なメリットを享受できると考えられているからである。

また、モノに搭載するデバイスは、コストや消費電力の面からロースペックであることが望まれる。そこで、小型デバイス上で、Ｗｅｂ技術の１つであるＪａｖａＳｃｒｉｐｔ（登録商標）を動作させるマイコンボードが開発されている。組み込みの世界では、低スペック上で動作させるために、例えばＣ言語等で書かれたプログラムをコンパイルして得られた実行形式のバイナリファイルを使うことが多い。しかしながら、ＪａｖａＳｃｒｉｐｔのようなスクリプト言語を使うことで、個々のデバイス向けの実行形式にコンパイルせずにアプリを実行することが可能であるため、様々なデバイス上でプログラムを動作させる場合に有用である。

また近年では、腕時計型端末（スマートウォッチ）や眼鏡型端末（スマートグラス）等といったウェアラブルデバイスのように低スペックでありながら汎用的なアプリを動作させたい機器の普及が始まりつつある。このようなデバイスを普及させるには、多くの開発者がアプリを作ることができる環境を用意することが重要であり、ＪａｖａＳｃｒｉｐｔのようなＷｅｂ技術が重要になる。一方で、ＪａｖａＳｃｒｉｐｔのようなスクリプト言語には、コンパイルされたバイナリを実行することに比べて動作が遅いという問題がある。そのため、ＪａｖａＳｃｒｉｐｔエンジンには、様々な高速化技術が実装されている。例えばＧｏｏｇｌｅ（登録商標）のＪａｖａＳｃｒｉｐｔエンジンであるＶ８では、ｆｕｌｌ−ｃｏｄｅｇｅｎ，ｃｒａｎｋｓｈａｆｔと呼ばれるＪｕｓｔ ｉｎ Ｔｉｍｅコンパイラが搭載されている。そして、ＪａｖａＳｃｒｉｐｔを実行する際には、デバイス上でＪａｖａＳｃｒｉｐｔのソースコードを読み込んだ後、コンパイルしてから実行している。

特開２００９−２１１１９０号公報 特開２００２−１６３１１５号公報 特表２０１３−５１６７２０号公報 特開２００７−１７９１５３号公報

しかしながら、上述したような技術は、例えばＰｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ（ＰＣ）やスマートフォン等の比較的高スペックなデバイス（情報処理装置）を対象としており、処理を実行するために多くのリソース（高速なＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）、大きなメモリ領域）が必要である。また、小型デバイス等への組み込み用のＪａｖａＳｃｒｉｐｔエンジンは、低スペックで動作可能なように、シンプルなインタプリタとして実行され、コンパイルなしで、逐次スクリプトを解析（パーズ）しながら実行するため、動作速度は遅い。

一つの側面では、本発明は、効率的にプログラムを実行することを目的とする。

一つの態様では、処理実行プログラムは、読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、前記ソースコードに含まれる関数をコールバック関数として登録し、前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて記憶し、所定のイベントに対応させて登録した前記コールバック関数を呼び出した場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する、処理をコンピュータに実行させる。

一つの側面として、効率的にプログラムを実行することができる。

情報処理装置の機能構成の一例を示す図である。 情報処理装置のハードウェア構成の一例を示す図である。 第１実施形態におけるスクリプト実行処理の一例を示すフローチャートである。 メモリ管理処理の一例を示すフローチャートである。 第２実施形態におけるスクリプト実行処理の一例を示すフローチャートである。 イベント抽出処理の一例を示すフローチャートである。 本実施形態におけるアーキテクチャと実装例を示す図である。 中間コードの生成とオブジェクト管理ツリーを説明するための図である。 本実施形態における動作概要を説明するための図である。 関数使用表の一例を示す図である。

以下、添付図面を参照しながら実施例について詳細に説明する。

＜情報処理装置の機能構成例＞
図１は、情報処理装置の機能構成の一例を示す図である。図１の例に示す情報処理装置１０は、記憶部１１と、読み込み部の一例としてのロード部１２と、解析部の一例としてのパーズ部１３と、実行部１４と、関数定義抽出部１５と、関数コール抽出部１６と、関数情報管理部１７と、中間表現管理部の一例としての中間コード管理部１８とを有する。

記憶部１１は、本実施形態におけるＪａｖａＳｃｒｉｐｔを用いた各種情報処理等を実行するためのソースコード２１等が記憶される。なお、記憶部１１は、例えば中間表現（例えば、中間コード等）やコールバックデータ、関数使用表、各種設定情報、実行途中で得られたデータ、実行結果（ログ）等を記憶してもよい。中間表現とは、ソースコード２１に含まれる関数全体についてパーズした結果をまとめたものである。中間表現は、メモリ上では、「変数」といった言葉で書かれているのではなく、記号に置き換えて記憶するためバイナリデータである。なお、中間表現は、コードに限定されるものではない。記憶部１１に含まれる各データは、ロード部１２以外の構成から読み込まれてもよい。記憶部１１は、ハードディスク等でもよく、メモリ等でもよく、それらの組み合わせでもよい。

ロード部１２は、記憶部１１等からＪａｖａＳｃｒｉｐｔ等の言語で記述されたソースコード２１をメモリ（例えばメモリキャッシュ）上等に読み込み、パーズ部１３にて解析可能な状態にする。

パーズ部１３は、メモリ上等に存在するソースコードを記述順序の最初（前）から順に構文解析や意味解析等の解析（パーズ）処理を行い、解析結果として実行可能なプログラム等を生成する。また、パーズ部１３は、関数情報管理部１７等により管理される中間コードから実行可能なプログラム等を生成してもよい。中間コードから処理を実行する場合は、パーズ部１３での処理にかかる時間がなくなるため、処理が高速化される。

実行部１４は、パーズ部１３により得られる解析結果を用いて処理を実行する。また、実行部１４は、ソースコード２１の代わりに中間コード等を使用して処理を実行することができる。実行部１４により実行された処理結果は、記憶部１１に記憶されてもよい。

関数定義抽出部１５は、ソースコード２１から関数定義された部分を抽出し、抽出した部分を関数情報管理部１７に出力する。

関数コール抽出部１６は、ソースコード２１から関数呼び出し部分を抽出して、関数情報管理部１７から対応する関数の中間コードやソースコード等を取得し、パーズ部１３に出力する。

関数情報管理部１７は、例えば関数定義抽出部１５や関数コール抽出部１６等から得られる関数（例えば、関数名や引数）、関数のソースコード、中間コード等の各情報の対応付けを管理する。例えば、関数情報管理部１７は、関数定義抽出部１５によりソースコード内に関数の定義が含まれると判断された場合に、関数を識別する関数名と、関数に対応するソースコードの中間コードとを対応付けて管理する。また、関数情報管理部１７は、得られた関数をオブジェクトの一例として、木構造（オブジェクト管理ツリー）を生成し、記憶部１１や関数情報管理部１７の内部メモリ上で管理する。

また、関数情報管理部１７は、ソースコード２１に含まれる関数をコールバック関数として登録するか否かを管理してもよい。関数をコールバック登録しておくことで、スクリプトを最後まで実行した後も、所定のイベントに対応させて登録した関数を呼び出して処理を実行することができる。

中間コード管理部１８は、中間表現の一例として例えば中間コード等を管理する。また、中間コード管理部１８は、メモリ管理や利用状況管理等を行い、例えば中間コードの作成や削除等を行う。例えば、中間コード管理部１８は、中間コードが存在しない場合に、中間コードを作成する。また、中間コード管理部１８は、使用メモリ状況に応じて、利用状況、中間コードの作成時間等に応じて優先順位をつけて、優先順位の低い中間コード等を削除する。

ここで、中間コード管理部１８について具体的に説明する。中間コード管理部１８は、中間コード作成部３１と、中間コード削除部３２と、メモリ管理部３３と、利用状況管理部３４とを有する。

上述した中間コード自身は、関数情報管理部１７により管理され、中間コード管理部１８では必要に応じて、中間コード作成部３１、中間コード削除部３２、メモリ管理部３３、及び利用状況管理部３４のうち、少なくとも１つの機能を呼び出す。

中間コード作成部３１は、中間コード管理部１８の指示に応じて関数のソースコードから中間コードを作成する。中間コード削除部３２は、中間コード管理部１８の指示に応じて中間コードを削除する。メモリ管理部３３は、中間コードをメモリに記憶することで使用されるメモリ使用量を管理する。また、メモリ管理部３３は、メモリ使用量の基準（例えば、閾値等）を設定しておく。これらの情報に基づいて、中間コード管理部１８は、中間コード削除部３２を呼び出すか否かを決定する。利用状況管理部３４は、その中間コードがいつ呼び出されたか、呼び出し頻度、作成時刻、呼び出された時のＣＰＵ負荷、中間コードを作成するのにかかる時間等の情報を管理し、この情報に基づいて、中間コード管理部１８が中間コード削除部３２によりどの関数の中間コードを削除するかを決定する。

上述したように、本実施形態における情報処理装置１０は、読み込んだソースコード２１の解析と実行とを繰り返してプログラム処理を行う際、関数情報管理部１７で管理する関数情報（例えば、関数名・引数・関数内のコード等）に加えて、中間コード管理部１８により中間コードを管理する。中間コードを用いることで、効率的にプログラムを実行することができる。

情報処理装置１０としては、例えばＰＣやタブレット端末であるが、これに限定されるものではなく、例えばスマートウォッチやスマートグラス、グローブ型、ペンダント型等のウェアラブル機器や、所定の環境下で設置されるセンサデバイス（温度センサ等）であってもよい。また、これらの各デバイスは、直接インターネットに接続して情報通信したり、Ｂｌｕｅｔｏｏｔｈ（登録商標）（例えば、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ等）やＷｉＦｉ（登録商標）等を使ってスマートフォン等と接続して情報通信してもよい。これらの通信によって、ＪａｖａＳｃｒｉｐｔで記述されたアプリ（プログラム）が各デバイス（情報処理装置１０）に配布されてもよい。

＜情報処理装置１０のハードウェア構成例＞
次に、情報処理装置１０のハードウェア構成例について、図を用いて説明する。図２は、情報処理装置のハードウェア構成の一例を示す図である。図２の例において、情報処理装置１０は、入力装置４１と、出力装置４２と、ドライブ装置４３と、補助記憶装置４４と、主記憶装置４５と、ＣＰＵ４６と、ネットワーク接続装置４７とを有し、これらはシステムバスＢで相互に接続されている。

入力装置４１は、ユーザ等が操作するキーボード及びマウス等のポインティングデバイスや、マイクロフォン等の音声入力デバイスを有しており、ユーザ等からのプログラムの実行指示、各種操作情報、ソフトウェア等を起動するための情報等の入力を受け付ける。

出力装置４２は、本実施形態における処理を行うためのコンピュータ本体（情報処理装置１０）を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイ等を有する。出力装置４２は、ＣＰＵ４６が有する制御プログラムによりプログラムの実行経過や結果等を表示することができる。

ここで、本実施形態において、例えばコンピュータ本体にインストールされる実行プログラムは、記録媒体４８等により提供される。記録媒体４８は、ドライブ装置４３にセット可能である。ＣＰＵ４６からの制御信号に基づき、記録媒体４８に格納された実行プログラムが、記録媒体４８からドライブ装置４３を介して補助記憶装置４４にインストールされる。

補助記憶装置４４は、例えばＨａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）やＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等のストレージ手段等である。補助記憶装置４４は、ＣＰＵ４６からの制御信号に基づき、本実施形態における実行プログラム（処理実行プログラム）や、コンピュータに設けられた制御プログラム等を記憶し、必要に応じて入出力を行う。補助記憶装置４４は、ＣＰＵ４６からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込むことができる。

主記憶装置４５は、ＣＰＵ４６により補助記憶装置４４から読み出された実行プログラム等を格納する。主記憶装置４５は、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）やＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）等である。補助記憶装置４４及び主記憶装置４５は、上述した記憶部１１の一例である。

ＣＰＵ４６は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）等の制御プログラム、及び主記憶装置４５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して各処理を実現する。プログラムの実行中に必要な各種情報等は、補助記憶装置４４から取得することができ、また実行結果等を格納することもできる。

具体的には、ＣＰＵ４６は、例えば入力装置４１から得られるプログラムの実行指示等に基づき、補助記憶装置４４にインストールされたプログラムを実行させることにより、主記憶装置４５上でプログラムに対応する処理を行う。例えば、ＣＰＵ４６は、処理実行プログラムを実行させることで、上述したロード部１２におけるソースコード２１の読み込みや、パーズ部１３におけるソースコードの解析、実行部１４におけるスクリプトに対応するプログラムの実行等の処理を行う。また、ＣＰＵ４６は、処理実行プログラムを実行させることで、上述した関数定義抽出部１５による関数定義の抽出、関数コール抽出部１６による関数コールの抽出、関数情報管理部１７における関数情報の管理等の処理を行う。また、ＣＰＵ４６は、処理実行プログラムを実行させることで、上述した中間コード管理部１８における中間コードの管理等の処理を行う。ＣＰＵ４６における処理内容は、上述した内容に限定されるものではない。ＣＰＵ４６により実行された内容は、必要に応じて補助記憶装置４４等に記憶される。

ネットワーク接続装置４７は、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）やインターネット等に代表される通信ネットワークを介して外部装置等との通信を行う。ネットワーク接続装置４７は、ＣＰＵ４６からの制御信号に基づき、通信ネットワーク等と接続することにより、実行プログラムやソフトウェア、設定情報等を外部装置等から取得する。また、ネットワーク接続装置４７は、プログラムを実行することで得られた実行結果又は本実施形態における実行プログラム自体を外部装置等に提供する。ネットワーク接続装置４７は、例えば上述したＢｌｕｅｔｏｏｔｈやＷｉＦｉ等を用いて外部装置等との無線通信を実現することができる。

記録媒体４８は、上述したように実行プログラム等が格納されたコンピュータで読み取り可能な記録媒体である。記録媒体４８は、例えばフラッシュメモリ等の半導体メモリやＣＤ−ＲＯＭ、ＤＶＤ等の可搬型の記録媒体であるが、これに限定されるものではない。

図２に示すハードウェア構成に実行プログラム（例えば、処理実行プログラム等）をインストールすることで、ハードウェア資源とソフトウェアとが協働して本実施形態におけるスクリプト実行処理等を実現することができる。

＜スクリプト実行処理の一例＞
次に、本実施形態におけるスクリプト実行処理の一例についてフローチャートを用いて説明する。

＜スクリプト実行処理：第１実施形態＞
図３は、第１実施形態におけるスクリプト実行処理の一例を示すフローチャートである。図３の例において、ロード部１２は、記憶部１１等からＪａｖａＳｃｒｉｐｔのソースコード２１を読み込む（Ｓ０１）、また、パーズ部１３は、スクリプトを解析（パーズ）する（Ｓ０２）。

次に、関数定義抽出部１５は、Ｓ０２の処理から得られる解析結果において、関数定義された部分が抽出されたか否かを判断し（Ｓ０３）、抽出された場合（Ｓ０３において、ＹＥＳ）、関数コードを記憶する（Ｓ０４）。また、Ｓ０３の処理において、関数定義された部分が抽出されなかった場合（Ｓ０３において、ＮＯ）、関数コール抽出部１６は、関数呼び出し部分が抽出されたか否かを判断する（Ｓ０５）。

関数呼び出し部分が抽出された場合（Ｓ０５において、ＹＥＳ）、関数情報管理部１７は、中間表現の一例である中間コードが存在するか否かを判断する（Ｓ０６）。中間コードが存在する場合（Ｓ０６において、ＹＥＳ）、中間コード管理部１８は、関数コードを取得し（Ｓ０７）、取得した関数コードを解析し（Ｓ０８）、解析結果を中間コードに追加する（Ｓ０９）。

次に、実行部１４は、関数コードを実行し（Ｓ１０）、取得した関数コードを最後まで実行したか否かを判断する（Ｓ１１）。ここで、実行部１４は、最後まで実行していない場合（Ｓ１１において、ＮＯ）、Ｓ０８の処理に戻る。また、Ｓ１１の処理において、最後まで実行した場合（Ｓ１１において、ＹＥＳ）、関数情報管理部１７は、関数と中間コードとの対応付けを記憶部１１等に記憶する（Ｓ１２）。次に、中間コード管理部１８は、中間コード等を記憶したメモリ等に対する管理処理（メモリ管理処理）を行う（Ｓ１３）。

また、Ｓ０６の処理において、中間コードが存在する場合（Ｓ０６において、ＹＥＳ）、実行部１４は、その中間コードを実行し（Ｓ１４）、最後まで実行したか否かを判断する（Ｓ１５）。最後まで実行していない場合（Ｓ１５において、ＮＯ）、実行部１４は、Ｓ１４の処理に戻る。また、Ｓ０５の処理において、関数呼び出し部分が抽出されていない場合（Ｓ０５において、ＮＯ）、実行部１４は、Ｓ０２の処理で解析したスクリプトを実行する（Ｓ１６）。

ここで、Ｓ０４，Ｓ１３，或いはＳ１６の処理後、又は、Ｓ１５の処理において、最後まえ実行した場合（Ｓ１５において、ＹＥＳ）、処理終了か否かを判断し（Ｓ１７）、処理を終了しない場合（Ｓ１７において、ＹＥＳ）、Ｓ０２に処理に戻り、例えば次のスクリプトの解析等を行う。また、Ｓ１７の処理において、読み込んだ全てのスクリプトを解析した場合やユーザにより終了指示等があった場合等のように、処理を終了する場合（Ｓ１７において、ＹＥＳ）、第１実施形態におけるスクリプト実行処理を終了する。

＜Ｓ１３：メモリ管理処理の一例＞
次に、上述したＳ１３におけるメモリ管理処理の一例についてフローチャートを用いて説明する。図４は、メモリ管理処理の一例を示すフローチャートである。図４に示すメモリ管理処理において、中間コード管理部１８は、中間コードのメモリ使用量を算出し（Ｓ２１）、全中間コードによるメモリ使用量を取得する（Ｓ２２）。

次に、中間コード管理部１８は、メモリ使用量が予め設定された閾値以上か否かを判断し（Ｓ２３）、閾値以上である場合（Ｓ２３において、ＹＥＳ）、利用状況を取得する（Ｓ２４）。利用状況とは、例えば中間コード毎に、いつ呼び出されたか、呼び出し頻度、作成時刻、呼び出された時のＣＰＵ負荷、中間コードを作成するのにかかる時間等の情報であるが、これに限定されるものではない。

次に、中間コード管理部１８は、取得した利用状況等に基づいて中間コードの優先順位を設定する（Ｓ２５）。Ｓ２５の処理では、最近呼び出されていない関数や、呼び出し回数が少ない関数等を優先順位を低くし、逆に最近呼び出されている関数や呼び出し回数が多い関数を優先順位を高く設定する等の処理を行うが、これに限定されるものではない。

次に、中間コード管理部１８は、優先順位の低いものから順にメモリ使用量が閾値以下になるまで中間コードを削除し（Ｓ２６）、Ｓ２６の処理により削除された中間コードに対応させて、関数と中間コードとの対応付けを削除する（Ｓ２７）。

また、Ｓ２３の処理において、メモリ使用量が閾値以上でない場合（Ｓ２３において、ＮＯ）、そのまま処理を終了する。

＜スクリプト実行処理：第２実施形態＞
次に、第２実施形態におけるスクリプト実行処理について説明する。第２実施形態では、Ｗｅｂ技術によって接続される情報処理装置（デバイス）１０の一例として、センサ等を備えた小型デバイスを想定する。小型デバイスが、センサの情報等を消費電力の観点から効率的に処理するためには、センサ等からの情報を受けて情報処理装置１０のＣＰＵ等がが動作し、処理終了後にはＣＰＵ等がスリープすることが望ましい。

そこで、情報処理装置１０は、センサや通信等によって得られた情報を、イベントとして受ける。そして、情報処理装置１０は、受け取った情報に基づいて計算を行い、その計算結果に応じて、別のデバイス（外部装置）等への情報通知を行う。例えば、情報処理装置１０は、温度センサからの入力イベントを受けて、温度が３０度を超えているかどうかの閾値チェックを行い、例えば温度が閾値を超えている場合にのみ、通信ネットワーク等を介して外部装置に通知するといった処理である。

この場合のイベントドリブンをＪａｖａＳｃｒｉｐｔで実現する。そのため、イベントに対応付けて、スクリプト関数をコールバックとして渡すことになる。その結果として、イベントの発生時にその渡した関数が呼び出されることになる。イベントが起こる毎に、関数が呼び出されることになるため、関数の実行を効率化することができる。上述した第２実施形態におけるスクリプト実行処理をフローチャートを用いて説明する。

図５は、第２実施形態におけるスクリプト実行処理の一例を示すフローチャートである。第２実施形態におけるスクリプト実行処理において、Ｓ３１〜Ｓ４５の処理は、上述した第１実施形態におけるスクリプト実行処理におけるＳ０１〜Ｓ１５の処理と同様の処理であるため、ここでの具体的な説明は省略する。

情報処理装置１０は、Ｓ３５の処理において、関数呼び出し部分が抽出されたか否かを判断し（Ｓ３５）、関数呼び出し部分が抽出されなかった場合（Ｓ３５において、ＮＯ）、関数情報管理部１７は、関数をコールバック関数として登録するか否かを判断する（Ｓ４６）。関数を登録する場合（Ｓ４７において、ＹＥＳ）、コールバック関数（コールバックデータ）として記憶部１１に登録する（Ｓ４７）。関数をコールバック登録しておくことで、スクリプトを最後まで実行した後も、登録した関数を呼び出すことができる。これにより、例えば、センサ等の値が取得できた場合に呼び出されたり、画面にタッチされたときに呼び出される等、所定のイベント発生に応じて関数が呼び出される。なお、イベント抽出は、ＪａｖａＳｃｒｉｐｔソースコードの実行とは独立して動作している。

また、Ｓ４６の処理において、関数を登録しない場合（Ｓ４６において、ＮＯ）、スクリプトを実行する（Ｓ４８）。また、情報処理装置１０は、Ｓ３４、Ｓ４３、Ｓ４７，或いはＳ４８の処理後、又は、Ｓ４５の処理において、最後まで実行した場合（Ｓ４５において、ＹＥＳ）、処理終了か否かを判断し（Ｓ４９）、処理を終了しない場合（Ｓ４９において、ＮＯ）、Ｓ３２の処理に戻る。また、Ｓ４９の処理において、処理を終了する場合（Ｓ４９において、ＹＥＳ）、第２実施形態におけるスクリプト実行処理を終了する。

＜イベント抽出処理について＞
ここで、図５に対応させたイベント抽出処理についてフローチャートを用いて説明する。図６は、イベント抽出処理の一例を示すフローチャートである。図６の例において、情報処理装置１０は、所定のイベントを抽出すると（Ｓ５１）、イベントに対応するコールバックを取得し（Ｓ５２）、記憶部１１等に登録されたコールバックデータから対応するコールバック関数を呼び出す（Ｓ５３）。

次に、関数情報管理部１７は、中間コードが存在するか否かを判断する（Ｓ５４）。中間コードが存在する場合（Ｓ５４において、ＹＥＳ）、中間コード管理部１８は、関数コードを取得し（Ｓ５５）、取得した関数コードを解析し（Ｓ５６）、解析結果を中間コードに追加する（Ｓ５７）。

次に、実行部１４は、関数コードを実行し（Ｓ５８）、取得した関数コードを最後まで実行したか否かを判断する（Ｓ５９）。ここで、実行部１４は、最後まで実行していない場合（Ｓ５９において、ＮＯ）、Ｓ５６の処理に戻る。また、Ｓ５９の処理において、最後まで実行した場合（Ｓ５９において、ＹＥＳ）、関数情報管理部１７は、関数と中間コードとの対応付けを記憶部１１等に記憶する（Ｓ６０）。また、情報処理装置１０は、上述したメモリ管理処理を行う（Ｓ６１）。

また、Ｓ５４の処理において、中間コードが存在する場合（Ｓ５４において、ＹＥＳ）、実行部１４は、その中間コードを実行し（Ｓ６２）、最後まで実行したか否かを判断する（Ｓ６３）。最後まで実行していない場合（Ｓ６３において、ＮＯ）、実行部１４は、Ｓ６２の処理に戻る。また、Ｓ６３の処理において、最後まで実行した場合（Ｓ６３において、ＹＥＳ）、又はＳ６１の処理後、処理を終了する。なお、図６のイベント抽出処理は、イベントが発生する毎に上述した処理が実行される。

＜本実施形態のアーキテクチャと実装例＞
次に、上述した本実施形態における情報処理装置１０を用いて、スクリプト関数の実行を効率化するためのアーキテクチャと実装例について、具体的に図を用いて説明する。図７は、本実施形態におけるアーキテクチャと実装例を示す図である。図７（Ａ）は、関数の実行を効率化するためのアーキテクチャ例を示し、図７（Ｂ）は、アーキテクチャーを実装するＪａｖａＳｃｒｉｐｔエンジンの実施例を示している。なお、図７（Ａ），（Ｂ）の例では、本実施形態における情報処理装置１０の機能構成の一部を概略的に示している。

図７（Ａ）に示すアーキテクチャの構成において、ライブラリ５１は、例えばセンサや通信（送受信）等に伴うイベントの発生に従って、コールバック登録された関数を呼び出す。例えば、ライブラリ５１は、例えばセンサや通信等に基づくイベントを待機し、イベントが発生した場合にコールバック登録された関数等を読み出すイベントループとしての機能であってもよい。

また、実行部１４は、上述したライブラリ５１やイベントループ等からの呼び出しを受けて、関数情報管理部１７から関数のソースコード又は中間コードを取得して、そのコードを実行する。

関数情報管理部１７は、関数のソースコードを管理する。また、実行部１４からの要求に応じて、関数のソースコード又は中間コードを返答する。中間コード管理部１８は、関数情報管理機能からの要求に応じて、関数の中間コードを返答する。必要に応じて、関数のソースコードをパーズして中間コードを作成したり、中間コードを削除する。

具体的には、要求された関数の中間コードが存在しない場合に、中間コード作成部３１により中間コードを作成してから返答し、存在する場合は作成せずに返答することになる。また、作成した中間コードを記憶部１１等に記憶しておくにはメモリ容量が必要であるため、不要になった場合や多くなりすぎて空きメモリが少なくなった場合に、中間コード削除部３２により所定の中間コードを削除する機能も持つ。

本実施形態では、中間コードを使用しなかった場合、つまり関数情報管理部１７がソースコードを返答する場合、ＪａｖａＳｃｒｉｐｔインタープリタの標準的な動作を行う。また、本実施形態では、ソースコードの代わりに中間コードを使うことで、関数をパーズする処理を省略することができ、その時間を短縮できることになる。パーズは、テキストで書かれたＪａｖａＳｃｒｉｐｔを字句解析及び構文解析する処理であるため時間がかかる。したがって、本実施形態を適用することで、時間短縮の効果が大きい。なお、図７（Ａ）に示すようなイベントドリブンモデルでは、イベントに対応する多くの関数は、関数単位で繰り返し呼ばれることになる。そのため、本実施形態では、関数毎に中間コードを管理する。

また、図７（Ｂ）に示す例では、ＪａｖａＳｃｒｉｐｔのソースコードをロードした後、そのソースコードを前から順にパーズと実行とを繰り返す（ロード／パーズ／実行）。そして、実行により得られたオブジェクトの一例である関数等を木構造（オブジェクト管理ツリー５２）として、記憶部１１等のメモリ上で管理する。このオブジェクト管理ツリー５２を使うことで、次回以降からそのオブジェクトを取得してアクセスすることができる。

ここで、上述した関数は、ソースコード２１のパーズ時に関数定義があった場合には、関数名と引数、関数部分のソースコードを対応付けて、オブジェクト管理ツリー５２に追加して管理される。また、コールバック登録があった場合には、ライブラリ５１を通してイベントと関数を対応付けて記憶する。

コールバック登録したことにより、イベント発生時に対応付けた関数が呼び出されることになる。関数呼び出し時には、そのオブジェクト管理ツリー５２を使って呼び出された関数に対応するソースコードを関数情報管理部１７経由で取得する。次に、パーズ部１３がその取得した関数部分のソースコードを解析する。そして、実行部１４が、その解析結果を用いて処理を実行する（関数実行）。つまり、本実施形態では、関数情報管理部１７における機能部分を拡張して、中間コード管理部１８における機能が動作するように実装することができる。なお、ここで管理する中間コードは、例えば関数のソースコードをステートメント毎にパーズして得られた結果から作成した木構造をリストにしたバイナリデータである。

例えば、図７（Ｂ）に示すように、オブジェクト管理ツリーを拡張して、関数名とそのソースコードの対応付けに加えて、中間コードへの対応付けを持たせる。そして、関数情報管理部１７は、関数呼び出し時に関数名でオブジェクト管理ツリーから関数のソースコードを取得するのに代えて、対応する中間コードが存在する場合は、中間コードを返答する。

実行部１４により、その中間コードを実行する。中間コードが存在しない場合は、関数のソースコードをパーズ・実行しながら、中間コード管理部１８が中間コードの作成を行い、オブジェクト管理ツリーに関数名と対応付けて記憶する。これにより、次回以降の呼び出し時に中間コードを使った実行が可能となり、高速化が実現される。

なお、上述した方法では、中間コードが作成されるのは、呼び出された関数に限られるが、例えば限定されたとしても、中間コードを記憶するためにメモリ領域が必要である。したがって、多くの関数があった場合に、小型デバイスではメモリの使用量が大きすぎることになり得る。そのため、中間コード削除部３２により中間コードを削除する機能を追加した。中間コードによって使用されるメモリ使用量を管理し、所定の使用量になった場合に、何れかの関数の中間コードを削除し、オブジェクト管理ツリー５２の対応付けを書き換える。その結果、中間コードを削除された関数が呼び出された場合にも、正常に実行することができる。

＜中間コードの生成とオブジェクト管理ツリーについて＞
次に、上述した本実施形態における中間コードの生成とオブジェクト管理ツリーについて、具体的に図を用いて説明する。

図８は、中間コードの生成とオブジェクト管理ツリーを説明するための図である。例えば、図８（Ａ）の左側に記述されたようなＪａｖａＳｃｒｉｐｔソースがあった場合、ｆｕｎｃｔｉｏｎから始まる関数定義の部分が抜き出されて管理される。本実施形態では、例えば図８（Ａ）に示すようにｗｉｎｄｏｗから始まるライブラリの呼び出しが実行されて、コールバック登録される。そして、対応するイベントが発生した時には、その登録された関数（例えばｌｉｓｔｅｎｅｒ）が呼び出される。その際、中間コードが存在する場合は、その中間コードを実行する。また、中間コードが存在しない場合は、パーズして中間コードを作成しながら実行する。そこで作られた中間コードは、関数（例えば、ｌｉｓｔｅｎｅｒ）と対応付けてバイナリデータとして記憶される。

このような場合における中間コードの生成において、まずＪａｖａＳｃｒｉｐｔのソースコードは、一連の表現（ｅｘｐｒｅｓｓｉｏｎ）をテキスト化したものである。例えば、以下のようなシンプルなソースコードを考える。
var x;
x = 1;
ＪａｖａＳｃｒｉｐｔエンジンは上記のソースコードを与えられた場合、例えばパーズ部１３等による字句解析、構文解析により、以下のような表現として解析する。
＜変数宣言（ｘ）＞＜名前（ｘ）＞
＜割り当て＞＜左辺＞＜名前（ｘ）＞
＜右辺＞＜整数（１）＞
上述した表現の１行目は、ＪａｖａＳｃｒｉｐｔの変数宣言のステートメントであり、これを１つの木構造として表現している。また、上述した表現の２行目は割り当てのステートメントであり、左辺、右辺両方を解析した上で１つの木構造として表現する。そして、これらをリスト化したものを中間コードとしてメモリ上に記憶する。なお、上述した内容は、説明の便宜上、言葉で表現しているが、実際にはそれぞれの表現に値を割り当てたバイナリデータで表現される。

次に、実行時に作成されるオブジェクト管理ツリーについて説明する。例えば、以下のようなソースコードを想定する。
var x = 1;
function func1(y) {
return y + 1;
}
このソースを実行した結果、オブジェクト管理ツリー５２に対して、変数オブジェクトｘに整数１が追加され、関数オブジェクトｆｕｎｃ１に引数「ｙ」とソースコード「ｒｅｔｕｒｎ ｙ＋１；」が追加される。そのオブジェクト管理ツリーのイメージを図８（Ｂ）（斜線部分以外）に示す。

ここで、関数の呼び出し時に関数名に基づいて、このオブジェクト管理ツリー５２を使って関数を検索して、その中間コードが存在する場合には、表現の一連である中間コードを取得して実行することになる。また、中間コードがない場合は、中間コード作成してオブジェクト管理ツリーの関数オブジェクトに追加して管理することになる。その部分を図８（Ｂ）の斜線部分で示す。

上述したように、本実施形態によれば、例えば小型デバイス等で動作するイベントドリブンのモデルを想定し、その上で動作させるＪａｖａＳｃｒｉｐｔエンジンの高速化アーキテクチャを実現することができる。その結果、小型デバイスで動作する単純な動作のスクリプトエンジンを効率的に動作させることができる。

また、使用メモリの管理機能や中間表現作成部分指定機能、一部の中間表現作成機能を持つことで、中間表現の作成によってメモリ使用量が増えすぎる問題を防ぐことができる。全体をコンパイルするのに比べて、メモリの使用量は小さい。

ここで、具体的なＪａｖａＳｃｒｉｐｔソースコードを用いた本実施形態における実行処理の動作例について説明する。図９は、本実施形態における動作概要を説明するための図である。中間表現とは、本来はスクリプトであるために、図９に示すように実行時には変数に値が入っている。例えば、図９に示すＪａｖａＳｃｒｉｐｔソースコードでは、「ｐａｒａｍ＋１」を実行する場合に、引数として与えられた「１０」に対し、１０＋１を計算すればよい。しかしながら、中間表現では、次に呼ばれた時には、引数が変わることがあるため（図９の例では、引数２０）、変数部分は変数として、実行時に値を置き換えられるように作成する必要がある。

そこで、本実施形態では、図９に示すように繰り返して実行されるＪａｖａＳｃｒｉｐｔソースコードの呼び出しを効率化する。そのため、本実施形態では、上述したように１度目のパーズ実行時にパーズ結果（解析結果）から得られる情報を記憶しておき、２度目以降の実行時に、その情報を利用してパーズ処理を省略することを可能とする。

例えば、ＪａｖａＳｃｒｉｐｔソースコードが与えられた時、ＪａｖａＳｃｒｉｐｔソースコードをメモリへ読み込み、ＪａｖａＳｃｒｉｐｔソースコードを前から順にパーズして、パーズ結果を元に実行することを繰り返す。例えば、図９に示すように、
var ａ = 1;
のようなソースコードがあった場合、「＜変数の宣言＞＜代入＞＜整数＞」といったようにその意味を理解して、その意味に基づいて変数のａと整数の１とを結び付ける。このような処理を繰り返すことになる。そこで、本実施形態では、関数の呼び出し時に中間表現を作成することで、実行を高速化する。また、例えば、図９に示すように、
function func１(param) {
return param + 1;
}
var result1 = func１(10);
var result2 = func１(20);
のようなスクリプトプログラムがある場合、図９（Ｂ）に示すように、最初の３行である関数定義部分において、関数名とソースコードの対応付けのみを記憶しておき、４行目の関数（var result1 = func１(10);）の呼び出し時には、その関数名に対応するソースコードについてパーズして中間表現を作成して対応付けに追加し、対応する処理を実行する。また、５行目の関数（var result2 = func１(20);）の呼び出し時には、パーズの代わりに（パーズせずに）、対応付けから得られるすでに作成された中間表現を使って対応する処理を実行することができる。

このように、本実施形態では、最初の関数の呼び出し時には、最初に中間表現（中間コード）を作成する時間が必要なだけで、２度目以降の呼び出し時にパーズする必要がない。その結果、小型デバイスで動作する単純な動作のスクリプトエンジンを効率的に動作させることができる。

また、本実施形態では、中間コード管理部１８において、使用メモリの管理機能や中間表現作成部分指定機能、一部の中間表現作成機能を有することで、中間表現の作成によってメモリ使用量が増えすぎる問題を防止ことができる。また、本実施形態では、全体をコンパイルするのに比べて、メモリの使用量は小さくなる。

＜ＪａｖａＳｃｒｉｐｔエンジンについて＞
ＪａｖａＳｃｒｉｐｔエンジンでは、グローバルソースと呼ばれる関数内ではない部分が、パーズ及び実行される。したがって、例えば上述した図９に示すＪａｖａＳｃｒｉｐｔソースコードの最初の行「ｖａｒ ａ＝１；」を解釈する。この場合は、＜変数（ａ）＞＜代入（＝）＞＜整数（１）＞ということを意味する。次の行は、関数の定義をしていることを意味する。＜関数（ｆｕｎｃ１）＞＜引数（ｐａｒａｍ）＞＜ソース（＜ｒｅｔｕｒｎ ｐａｒａｍ＋１；＞）＞と解釈される。これら（変数（ａ）及び関数（ｆｕｎｃ１））のオブジェクトは、後から使用される可能性がある。そのため、後から呼び出し時に見つけることができるように管理する必要がある。そのため、例えば上述した図８（Ｂ）のようなツリー構造で管理する。これにより、もし後から変数ａの値を使用しようとした場合は、このオブジェクト管理ツリーを辿ることで値を取得することができる。関数ｆｕｎｃ１を呼びだそうとした場合は、オブジェクト管理ツリーを辿ることで関数ｆｕｎｃ１のソースコードを取得することができる。そして、上述した例の最後の行のように実際に呼ばれた場合には、ｆｕｎｃ１のソースコードを取得して、その後、ソースコード内を実行する。

本実施形態では、オブジェクト管理ツリーに、オブジェクトに対応するソースコードに加えて、中間表現を管理できるように拡張する。上述した図８（Ｂ）の「Ｉｎｔｅｒｍｅｄｉａｔｅ」データの部分が中間表現に相当する。関数の呼び出し時には、対応する名前を持ったオブジェクトを見つけ出し、更にそのオブジェクトが中間表現を持っているかどうかを確認する。もし、持っていた場合は、ソースコードを取得する代わりに、中間表現を取得して、その中間表現を使用してＪａｖａＳｃｒｉｐｔの実行を行う。また、中間表現を持っていなかった場合は、ソースコードを取得して、ソースコードを中間表現に変換し、得られた中間表現をオブジェクト管理ツリーに追加する。そして、中間表現を使用してＪａｖａＳｃｒｉｐｔの実行を行う。

なお、中間表現は、メモリ上では、「変数」といった言葉で書かれているのではなく、記号に置き換えて記憶するためバイナリデータである。中間表現から実行する場合は、パーズにかかる時間がなくなるため、処理が高速化される。一方で、この方式では、中間表現を作って記憶するため、メモリの使用量が大きくなる。本実施形態で想定しているような組み込みデバイスでは、メモリ使用量が増えることは大きな問題である。そのため、この方法に因るメモリ使用量の増加を一定範囲に抑えることが重要である。そのために、本実施形態では、中間コード管理部１８において、中間表現によるメモリ使用量を管理する。

例えば、中間コード管理部１８は、中間表現を作成した場合、その中間表現であるバイナリデータのデータサイズを算出する。そして、中間表現によるメモリ使用量にこのデータサイズを追加する。そして、ある値（閾値）を超えた場合、中間表現の少なくとも１つを削除する。なお、どれを削除するかは、ランダムに削除する方法や最近使われていないもの、呼ばれた回数、古くに作成されたもの等に応じて優先順位を設定し、その優先順位に基づいて削除する方法等があるが、これらに限定されるものではない。また、上述した削除を実現するために、例えば関数使用表を記憶部１１等に記憶しておき管理することができる。

図１０は、関数使用表の一例を示す図である。図１０に示す関数使用表は、例えば記憶部１１に記憶され、必要に応じて読み込みや書き出しを行うことができる。図１０の例では、関数毎に、「作成時刻」、「最新呼び出し時刻」、「呼ばれた回数（回）」、「ＣＰＵ負荷（％）」等の項目が記憶されているが、関数の数や記憶される項目の種類については、これに限定されるものではない。このように、関数毎に管理を行い、記憶された関数情報に基づいて中間表現の削除対象を選択することができる。なお、削除については、例えば一つの関数の中間表現を削除しても、メモリ使用量が上限を超えている場合は、更に別の関数の中間表現も削除する。

また、関数使用表は、中間表現の作成対象を選択する場合に用いてもよい。また、関数使用表は、オブジェクト管理ツリーを拡張して管理してもよく、別の表として管理してもよい。これにより、メモリ等を使いすぎるのを防止することができる。なお、超えてはいけない使用量を判断するための閾値は、例えば固定値でもよく、またＯＳ等から空きメモリ領域のサイズを取得して、その値に基づいて動的に変更してもよい。なお、削除された中間表現の関数が再び呼び出される場合は、中間表現が存在しないことになるため、再度中間表現が作成される。

＜メモリ使用量削減例＞
次に、上述した中間コード管理部１８におけるメモリ使用量削減例について説明する。なお、以下の各実施例では、中間コードの作成時又は削除時におけるメモリ使用量削減例を示している。

＜実施例１＞
上述したように、中間コードを作成していくと時間の経過と共に多くのメモリを使用することになる。そこで、実施例１では、中間コードを記憶するための使用可能メモリを決定し、記憶した中間コードのメモリ量を管理する。また、実施例１では、作成された中間コードを記憶した場合のメモリ量を計算し、上限を超えていた場合、記憶されている中間コードのどれかを削除する。

また、中間コードをメモリキャッシュに置き、次回同じ関数が呼び出された時、その中間コードを使用することで、一部の処理を削減できる。

削除する中間コードの選択基準として、最も最近使われていないもの、一定期間内での頻度が少ないもの、最も古くに作成されたもの等から選択された少なくとも１つの手法を用いて使用量が所定の閾値以上にならなくなるまで削除を行う。なお、選択基準については、これに限定されるものではない。これにより、メモリ容量を使い過ぎないため、例えば小さいメモリ容量を有するデバイスでも利用することができる。

＜実施例２＞
実施例２では、作成された中間コードを記憶した場合のメモリ量を計算し、上限を超えていた場合、記憶されている中間コードのどれかをファイルに書き出し、メモリキャッシュから消す。次回同じ関数が呼び出された時、その中間コードを使用することで、一部の処理を削減できる。また、次回ファイルに書きだされた関数が呼び出された場合、中間コードをメモリキャッシュに読み込んでから実行する。上述したファイルの書き出しとメモリキャッシュからの削除を行う。

なお、中間コードをファイルに書き出した場合、その情報（例えば、ファイル名）は、例えばオブジェクト管理ツリーに追加しておき、その関数が呼び出された場合は、オブジェクト管理ツリーに基づいてファイルをロードして、ロードした中間コードを使用してもよい。

また、実施例２において、削除する中間コードの選択基準としては、上述したように最近使われていないもの、一定期間内での頻度が少ないもの、最も古くに作成されたもの等から順に閾値以下となるまで処理を行うことが好ましいがこれに限定されるものではない。これにより、メモリ容量を使い過ぎないため、小さいメモリのデバイスで利用できる。

＜実施例３＞
実施例３では、中間コード作成時に作成時間を測定し、記憶した中間コードのメモリ量を管理する。また、作成された中間コードを記憶した場合のメモリ量を計算し、上限を超えていた場合、作成時間に基づいて記憶されている中間コードの少なくとも１つを削除する。

中間コードの作成にかかる時間は、作成しようとしているソースコードの内容によって異なる。そのため、実施例３では、中間コード管理部１８において、中間コードを作成にかかった時間を管理し、削除が必要なときにはその時間情報を使って対象を選択する。この時間情報は、例えば上述した関数使用表を使って管理してもいいし、オブジェクト管理ツリーを使って管理してもよい。作成時間が短いものは、再度作ったとしても速度面で負担にはならない。

これにより、メモリ容量を使い過ぎないため、小さいメモリ容量を有するデバイスでも利用できる。また、中間コードの作成に時間がかかるものを再作成しないことで高速化が望める。

＜実施例４＞
実施例４では、デバイス（情報処理装置１０）のＣＰＵ負荷を用いて中間コードの作成や削除の対象を管理する。ＪａｖａＳｃｒｉｐｔの関数は、ユーザ操作があった場合や通信によりデータを受け取った場合、センサから情報を受け取った場合等、何かのイベントを受けて呼び出されることが多く、またイベントの発生は複数で連動することが多い。例えば、ユーザがデバイスを操作しているときはタッチやスワイプといった操作のイベント等と連続して発生することが考えられる。逆に、１分に一回しか呼ばれないタイマイベント等も考えられる。

このような場合、前者の方が頻繁に関数を呼び出すことになり、反応を早くするために、より速い動作をすることが望ましく、後者は前者に比べると遅くてもいい。したがって、実施例４では、ＣＰＵ負荷を見て、ＣＰＵ負荷が高い部分については中間コードを使用するのが好ましい。また、実施例では、関数が呼び出された場合のＣＰＵ負荷を管理し、ＣＰＵ負荷が低い時に呼び出された関数は削除する。更に、実施例４では、逆に何度も呼び出された場合のみ、中間コードを記憶する方法をとってもよい。これは、関数の呼ばれた回数を関数使用表等で管理することで実現できる。

＜実施例５＞
例えば、中間コードを作るのに時間がかかるので、あまり呼び出されない場合は作るほうが遅くなる。そのため、実施例５では、関数に所定のコメント情報を付けておき、そのコメント情報に基づいて中間コードを作成するか否かを決定する。例えば、実施例５では、例えばソースコード中にコメントで決まりを作ったり（例えば関数の前に「／／＠ｎｏｇｅｎ」を付与する等）、関数名に決まりを作る（例えば関数名の最後に「ｎｏｇｅｎ」を付与する等）。

例えば、実施例５では、ユーザ（開発者等）が中間表現を記憶しない関数を指定する。この場合、ＪａｖａＳｃｒｉｐｔの特徴である汎用性（ＪａｖａＳｃｒｉｐｔエンジンがあればどこでも動作する）が阻害されてはいけない。したがって、例えば、コメントとして、情報を記述する。もしくは関数名の命名方法に決まりを作る方法がある。この方法を使った場合、以下のようになる。
// @nogen
function func1(param) {
return param + 1;
}
function func2(param) {
return param + 2;
}
function func3_nogen(param) {
return param + 3;
}
上述した例は、「＠ｎｏｇｅｎ」とついたコメントが付いているｆｕｎｃ１は中間コードを記憶せず、関数名に「＿ｎｏｇｅｎ」が付いているｆｕｎｃ３＿ｎｏｇｅｎも中間コードにしないことを意味する。実施例５の処理は、例えば中間コードを作成しないことを示す情報を、オブジェクト管理ツリーを拡張して管理することで実現できる。また、実施例５は、ユーザ（開発者等）が設定することでより効果的な方法を設定することができる。これにより、無駄な中間コードを作成しないため、実行が速くなると共にメモリ使用量も減らすことができる。

＜実施例６＞
また、使われないコードの中間表現をとるのは無駄であるため、例えばほとんど実行される可能性のないエラー処理等については、何からの処理が必要となる。そこで、実施例６では、中間コード作成時に、実行しながら中間コードを作成する。その中間コードを作成する際は、実行時に通らなかった部分は、中間コードにしない（例えばｉｆ文で分岐した場合等）。

そして、実施例６では、通らなかった部分はソースコードのままにしておき、次回以降の呼び出しでその部分が実行された場合は、その部分の中間言語を作成する。

例えば、実施例６では、まず関数全体について中間コードを作成し、次にその中間コードを実行する。しかしながら、インタプリタが逐次解釈して実行することを繰り返すのと同様に行うことも可能である。そして、実施例６の方法を取る場合、一部の中間コードのみを作成することが可能である。例えば、以下のような関数があるとする。
function func4(a) {
if (a > 0) {
return a;
} else {
return -a;
}
var result = func4(-1);
この場合、最後の行「var result = func4(-1);」で引数−１を持って関数呼び出しがされ、関数ｆｕｎｃ４のソースコードを取得する。そして、最初の行を解釈し＜分岐＞＜条件＜変数（ａ）＞＜比較（＞）＞＜整数（０）＞＞となり、これを中間表現とする。次に、実行中なので、この結果も算出できる。ａには−１が入っているため、ｅｌｓｅ側のみ中間表現とする。＜条件付き実行（ｅｌｓｅ）＞＜戻り値＞＜計算（−）＞＜変数（ａ）＞と解釈し、これだけの中間表現を作成する。そして、実行としては、１を返却することになる。このように、部分のみを作ることが可能になる。関数の中には、ほとんど使われない部分がある。そのような部分を中間コードにすることを防止し、メモリを有効利用できる。なお、もし、ａ＝１だった場合等、逆の条件の実行が必要な場合は、そのときにその部分のみ中間コードを作成して追加することで対応することができる。これにより、無駄な中間コードを作成しないため、実行が速くなると同時にメモリ使用量も減る。

上述したように本実施形態によれば、効率的にプログラムを実行することができる。また、本実施形態によれば、例えば使用メモリ量に応じて中間表現を作成したり、削除したりすることで、中間表現作成時にメモリ容量を測定し管理することができる。

例えば、最初の関数の呼び出し時には、中間表現を作成する処理を行うが、２度目以降の呼び出し時にパーズする必要がない。そのため、例えば小型デバイス等で動作する単純な動作のスクリプトエンジンを効率的に動作させることができる。また、本実施形態によれば、中間表現の作成によってメモリ使用量が増えすぎるのを防止することができる。また、本実施形態によれば、アプリやプログラム全体をコンパイルするのに比べて、メモリの使用量は小さくなる。

以上、実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、上述した各実施例の一部又は全部を組み合わせることも可能である。

なお、以上の実施例に関し、更に以下の付記を開示する。
（付記１）
読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、
前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて記憶し、
前記関数を呼び出す場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、
対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、
対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する、
処理をコンピュータに実行させるための処理実行プログラム。
（付記２）
前記中間表現により使用される記憶部の使用量を管理し、
作成した前記中間表現を記憶した場合の前記使用量が所定の閾値以上である場合に、記憶された少なくとも１つの中間表現を削除することを特徴とする付記１に記載の処理実行プログラム。
（付記３）
前記中間表現の利用状況を管理し、
前記利用状況に応じて前記記憶部から削除する中間表現を選択することを特徴とする付記２に記載の処理実行プログラム。
（付記４）
前記中間表現の作成時間を管理し、
前記作成時間に応じて前記記憶部から削除する中間表現を選択することを特徴とする付記２に記載の処理実行プログラム。
（付記５）
前記ソースコード内に含まれる関数の実行時における情報処理装置のＣＰＵ負荷に基づいて、前記中間表現を作成するか否かを判断することを特徴とする付記１乃至４の何れか１項に記載の処理実行プログラム。
（付記６）
前記ソースコードに含まれるコメント情報に基づいて前記中間表現を作成するか否かを判断することを特徴とする付記１乃至５の何れか１項に記載の処理実行プログラム。
（付記７）
前記中間表現の作成時に、前記関数の全体ではなく、初回の実行時に使った部分のみの中間表現を作成し、
次回の呼び出し以降で別の部分を実行した場合に、前記別の部分の中間表現を作成することを特徴とする付記１乃至６の何れか１項に記載の処理実行プログラム。
（付記８）
前記ソースコードに含まれる関数をコールバック関数として登録し、所定のイベントに対応させて登録した関数を呼び出して処理を実行することを特徴とする付記１乃至７の何れか１項に記載の処理実行プログラム。
（付記９）
情報処理装置が、
読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、
前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて記憶し、
前記関数を呼び出す場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、
対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、
対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する、
ことを特徴とする処理実行方法。
（付記１０）
読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて管理する関数情報管理部と、
前記関数を呼び出す場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する中間表現管理部とを有することを特徴とする情報処理装置。

１０ 情報処理装置
１１ 記憶部
１２ ロード部（読み込み部）
１３ パーズ部（解析部）
１４ 実行部
１５ 関数定義抽出部
１６ 関数コール抽出部
１７ 関数情報管理部
１８ 中間コード管理部（中間表現管理部）
２１ ソースコード
３１ 中間コード作成部
３２ 中間コード削除部
３３ メモリ管理部
３４ 利用状況管理部
４１ 入力装置
４２ 出力装置
４３ ドライブ装置
４４ 補助記憶装置
４５ 主記憶装置
４６ ＣＰＵ
４７ ネットワーク接続装置
４８ 記録媒体
５１ ライブラリ
５２ オブジェクト管理ツリー

Claims (8)

1. 読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、
   前記ソースコードに含まれる関数をコールバック関数として登録し、
   前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて記憶し、
   所定のイベントに対応させて登録した前記コールバック関数を呼び出した場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、
   対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、
   対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する、
   処理をコンピュータに実行させるための処理実行プログラム。
2. 前記中間表現により使用される記憶部の使用量を管理し、
   作成した前記中間表現を記憶した場合の前記使用量が所定の閾値以上である場合に、記憶された少なくとも１つの中間表現を削除することを特徴とする請求項１に記載の処理実行プログラム。
3. 前記中間表現の利用状況を管理し、
   前記利用状況に応じて前記記憶部から削除する中間表現を選択することを特徴とする請求項２に記載の処理実行プログラム。
4. 前記中間表現の作成時間を管理し、
   前記作成時間に応じて前記記憶部から削除する中間表現を選択することを特徴とする請求項２に記載の処理実行プログラム。
5. 前記ソースコード内に含まれる関数の実行時における情報処理装置のＣＰＵ負荷に基づいて、前記中間表現を作成するか否かを判断することを特徴とする請求項１乃至４の何れか１項に記載の処理実行プログラム。
6. 前記ソースコードに含まれるコメント情報に基づいて前記中間表現を作成するか否かを判断することを特徴とする請求項１乃至５の何れか１項に記載の処理実行プログラム。
7. 情報処理装置が、
   読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、
   前記ソースコードに含まれる関数をコールバック関数として登録し、
   前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて記憶し、
   所定のイベントに対応させて登録した前記コールバック関数を呼び出した場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、
   対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、
   対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する、
   ことを特徴とする処理実行方法。
8. 読み込んだソースコードの解析と実行とを繰り返してプログラム処理を行う際、前記ソースコードに含まれる関数をコールバック関数として登録する登録部と、
   前記ソースコード内に関数の定義が含まれる場合に、前記関数を識別する関数名と、前記関数に対応するソースコードの中間表現とを対応付けて管理する関数情報管理部と、
   所定のイベントに対応させて登録した前記コールバック関数を呼び出した場合に、前記関数に対応する前記中間表現が記憶されているか否かを判断し、対応する前記中間表現が記憶されている場合は、記憶された前記中間表現を用いて前記関数に対応する処理を実行し、対応する前記中間表現が記憶されていない場合は、前記関数に対応するソースコードを解析して中間表現を作成する中間表現管理部とを有することを特徴とする情報処理装置。

Images