(57)【要約】【課題】起動時にロードされるクラス群を特定し、それらのクラス群に限定したライブラリの最適化を施すことで起動時間を短縮する。また、それらのクラス群に限り、検証処理をおこなったことを示す情報を持つことにより、安全かつ効果的に起動時間を短縮する。【解決手段】高速化プログラムは、アプリケーション・プログラムの起動時におけるロード処理をプロファイルし、起動時にロードされたクラス群を先頭から順に格納した変換後ライブラリを出力する。そして、クラスロード部は、変換後ライブラリを用いて起動時にロードされたクラス群を特定し、それらのクラス群に限定した最適化をおこなう。また、それらのクラス群に限り、ベリファイをおこなったときに、ベリファイ済みフラグをセットし、ＯＮのときにはベリファイをおこなわないようにする。【選択図】        図２
2006350489.tif 000002
【特許請求の範囲】
【請求項１】
一つ以上のコンピュータ・プログラムのプログラムコードを格納したライブラリから、前記プログラムコードを要求に応じてロードし、あるプログラムを起動して処理を実行するプログラム制御方法において、
ロードされたプログラムコードの識別情報と、前記プログラム起動時の前記プログラムコードのロード順序と、前記プログラム起動時の前記プログラムコードの総数とが格納されたプロファイルを設定するステップと、
前記プロファイルに基き前記プログラム起動時にロードされるプログラムコードを特定し、前記ライブラリから前記プログラム起動時にロードされるプログラムコードを先頭部分に配置した変換後ライブラリを作成するステップと、
前記変換後ライブラリ内に、ライブラリの配置情報と前記プログラム起動時の前記プログラムコードの総数とを記憶するステップとを有することを特徴とするプログラム制御方法
【請求項２】
前記プログラム起動時にロードされるプログラムを、前記変換後ライブラリに基き、前記プログラム起動時に一括ロードすることを特徴とする請求項１記載のプログラム制御方法。
【請求項３】
前記変換後ライブラリの先頭部分に配置されたプログラムコードが、前記プログラム起動時のロードされる順番に並べられていることを特徴とする請求項１記載のプログラム制御方法。
【請求項４】
前記ロードされるプログラムコードから、さらにロードされるプログラムコードを、ロードする元のプログラムコードよりも先頭に配置することを特徴とする請求項１記載のプログラム制御方法。
【請求項５】
前記プログラム起動時にロードされるプログラムコードを、前記変換後ライブラリに基き、そのプログラムコードに対してロードの要求があったときに検索し、ロードすることを特徴とする請求項３記載のプログラム制御方法。
【請求項６】
プログラムコードの実行時または実行前にそのプログラムコードの安全性を確認するための検証処理をおこなうプログラム制御方法であって、
さらに、前記プログラム起動時にロードされるプログラムコードに対して前記検証処理をおこなったことを示す検証済フラグを記憶装置に記憶するステップと、
前記検証済フラグにより、安全性の検証をおこなったか否かを判定し、安全性の検証をおこなったことを示しているときには、前記プログラム起動時にロードされるプログラムコードに対して安全性の検証をおこなわないことを特徴とする請求項１記載のプログラム制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム制御方法に係り、特に、Ｊａｖａ（登録商標）の中間コードをＶＭ上で実行するにあたり、Ｊａｖａのクラスライブラリのロードを高速化し、安全性を確保しうる用途に用いて好適なプログラム制御方法に関する。
【背景技術】
【０００２】
従来、実行時の要求に応じてプログラムコードをロードし、これをインタプリタにて実行するコンピュータ・プログラム実行環境が提唱されている。このような環境を提供するものとして、Ｊａｖａのプラットホームがある。このＪａｖａのプラットホームでは、コンピュータ・プログラムのソースコードを中間コードと呼ばれる仮想的なプログラム命令に変換し、これを逐次解釈実行する。中間コードはクラスと呼ばれるモジュール単位で圧縮ファイルに格納され、実行環境によってクラスが参照されると同時にロードされ、実行される。クラスは圧縮ファイル内の任意の場所に格納されるため、クラスをロードする際には、圧縮ファイルのヘッダ情報から目的のクラスを検索しなければならない。
【０００３】
クラスのロードを高速化する従来技術として、以下の非特許文献１ではクラスをロードする順番で圧縮ファイルに格納することにより、クラスの検索処理を高速化している（以下、従来方式１と記す）。また、非特許文献１ではコンピュータ・プログラムの開始時に連続して全てのクラスをロードすることで、実行時のロードを不要にする方法が開示されている（以下、従来方式２と記す）。さらに、クラスを一つのバイナリファイルへまとめ、ファイルの先頭にクラスのオフセットと名前を持つヘッダを持たせることでクラスのロード処理を高速化する技術が開示されている（以下、従来方式３と記す）。
【０００４】
また、中間コードが安全に実行可能であるかを検証する機能（以下、「ベリファイ機能」という）を備えた実行環境が存在する。この実行環境ではコンピュータ・プログラムの実行時あるいは実行前に中間コードの検証をおこなうことで、コンピュータ・プログラムをより安全に実行できる。一般に、中間コードの安全性を検証する処理（以下、「ベリファイ処理」という）は複雑であるため、ベリファイ機能を備えた実行環境では、ベリファイ機能を持たない実行環境に比べてクラスのロードに時間がかかる。
【０００５】
ベリファイ処理を高速化する従来技術として、実行環境のコマンドラインオプションによってベリファイ機能を無効化する方式がある（以下、従来方式４と記す）。さらにベリファイ処理の一部を事前におこない、結果をクラス内に格納することで実行時のベリファイ処理を軽減する方式が一般に知られている（以下、従来方式５と記す）。
【０００６】
【非特許文献１】Jack Shirazi著「Javaパフォーマンスチューニング第２版」株式会社オライリー・ジャパン、2003年10月25日、P.99
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来方式１は、クラスのライブラリ内の配置を工夫することにより、ロードにかかる時間を高速化しようとするものである。
【０００８】
しかしながら、従来方式１は、クラスのロード順序が確定している必要があるため、クラスのロード順序にばらつきのあるコンピュータ・プログラムでは検索処理を実行する必要がある。また、従来方式２は、全てのクラスをロードしてしまうため、起動時に不要なクラスのロード処理が発生するという問題点がある。従来方式３は、従来の形式とは互換性のないファイル形式を採用するため、特殊な実行環境に利用が制限されてしまうという問題点がある。
【０００９】
また、上記従来方式４は、プログラムの実行時において、完全にベリファイ処理を省略してしまうものである。したがって、その分の時間は、高速化されるが安全性に問題がある。従来方式５は、クラスに特殊なデータを追加するためファイルサイズが増加し、かつ、ベリファイ処理を省略することはできない。
【００１０】
このように、プログラムコードを実行時の要求に応じてロードし、リンクさせることで処理を実行するコンピュータ・プログラム、特に、命令の実行時または実行前にプログラムコードの安全性を検証するためのベリファイ処理をおこなうコンピュータ・プログラムにおいて、起動処理の高速化に最も適した方式は提案されていなかった。
【００１１】
本発明は、上記問題点を解決するためになされたもので、その目的は、プログラムコードを実行時の要求に応じてロードし、リンクさせることで処理を実行するコンピュータ・プログラムの制御方法において、起動時の処理を高速化し、安全性を確保するプログラムの制御方法を提供することにある。
【課題を解決するための手段】
【００１２】
本発明は、高速化対象となるコンピュータ・プログラムに対し、プロファイラと呼ばれる解析プログラムによる解析処理をおこなうことで起動時に必要なプログラムコード群を特定し、それらプログラムコード群に限定した最適化をおこなうことで起動時間を短縮するアプリケーション起動高速化方法である。プロファイラは高速化対象となるコンピュータ・プログラムの起動処理の終了を判定する機能を持ち、起動処理の終了までロード処理を監視する。
【００１３】
そして、ロードされたプログラムコードを一意に特定するためのプログラムコード識別情報と、プログラムコードがロードされた順序を表す起動時ロード順序と、起動時にロードされたプログラムコードの総数を表す起動時プログラムコード数とを含んだプロファイルデータを出力する。
【００１４】
次に、出力されたプロファイルデータから起動時にロードされた起動時プログラムコード群を特定し、起動時プログラムコード群が格納されている共有ライブラリを起動時プログラムコード群が先頭部分に格納されるよう並べ替えた変換後ライブラリを作成する。また、ライブラリの配置情報を表すロード順フラグ、逆順フラグと、起動時プログラムコード数とを変換後ライブラリのデータ記憶領域に記憶する。
【００１５】
これにより、変換後ライブラリから起動時プログラムコード数を読み込むことで起動時プログラムコード群を容易に特定でき、起動時プログラムコード群に限定した効率的な最適化処理を施すことが可能になる。また、変換後ライブラリは変換前のライブラリと互換性を持つため、他の実行環境でも同様に変換後ライブラリを利用することができる。さらに、変換後ライブラリへ追加されるデータはフラグデータとプログラムコード数のみであるため、増加するデータサイズは数バイト程度と小さい。
【００１６】
また、前記変換後ライブラリを利用し、コンピュータ・プログラムの起動開始時において、一度に全ての起動時プログラムコード群をロードすることで、プログラムコードのロード順序にばらつきのあるコンピュータ・プログラムであっても検索処理を省略できる。さらに、起動時に不要なプログラムコードをロードしないため、効率的に起動時間を短縮することができる。
【００１７】
また、プログラムコードの実行時または実行前にプログラムコードの安全性を検証するためのベリファイ機能を備えたコンピュータ・プログラムにおいて、プログラムコードの初回実行時にベリファイ処理をおこない、ベリファイ処理をおこなったことを表すベリファイ済フラグを記憶装置に記憶し、ベリファイ済フラグを判定することで二度目の実行からは起動時プログラムコード群に限定してベリファイ処理を省略する。
【００１８】
これにより、起動時プログラムコード群に限定してベリファイ処理を省略することができるため、ベリファイ処理の省略範囲を最小限に抑えることができ、安全かつ効果的に起動時間を短縮することができる。
【発明の効果】
【００１９】
本発明によれば、プログラムコードを実行時の要求に応じてロードし、リンクさせることで処理を実行するコンピュータ・プログラムの制御方法において、起動時の処理を高速化し、安全性を確保するプログラムの制御方法を提供することができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明に係る各実施形態を、図１ないし図１４を用いて説明する。
【００２１】
〔システム構成と処理概要〕
先ず、図１および図２を用いて本発明の一実施形態に係るコンピュータシステムの構成とプログラム制御方法の処理の概要について説明する。
図１は、本発明の一実施形態に係るコンピュータシステムの構成図である。
【００２２】
本システムは、コンピュータ１１１またはそれに類する機器構成により構成される。機器構成１１１はＣＰＵなどの演算装置１０１と、ＨＤＤやリムーバブルメディアなどの記憶装置１０３と、記憶装置１０３よりも高速に動作する主記憶装置１０２と、キーボードやマウスなどの入力装置１０４と、ディスプレイなどの出力装置１０５と、ネットワーク通信をおこなうことが可能な通信装置１０６とを備える。
【００２３】
中間コード実行プログラム１０７および高速化プログラム１０８は記憶装置１０３上に記憶されているコンピュータ・プログラムであり、演算装置１０１によって主記憶装置１０２上に展開され、実行される。中間コード実行プログラム１０７および高速化プログラム１０８は中間コードと呼ばれる仮想的なプログラム命令を解釈し、実行することができる。中間コードはクラスと呼ばれるモジュール単位で共有ライブラリ１０９および変換後ライブラリ１１０に格納される。共有ライブラリ１０９および変換後ライブラリ１１０は、圧縮されたファイルであり、記憶装置１０３上に記憶される。ただし、共有ライブラリ１０９および変換後ライブラリ１１０は複数あっても良く、圧縮されていなくても良い。なお、中間コード実行プログラム１０７、高速化プログラム１０８、共有ライブラリ１０９、および変換後ライブラリ１１０は、同じ記憶装置１０３上になくても良く、インターネットなどのネットワークを経由した別のコンピュータ１１１上にあっても良い。
【００２４】
次に、図２を用いて本発明のアプリケーション・プログラムの起動を高速化するためのプログラム制御方法について説明する。
図２は、本発明のアプリケーション・プログラムの起動を高速化するためのプログラム制御方法の処理の概要を示す図である。
【００２５】
なお、高速化対象となるコンピュータ・プログラムのことを、特に、「アプリケーション・プログラム」と呼ぶ。アプリケーション・プログラムは、共有ライブラリ１０９に格納された複数のクラスによって構成される。本発明のアプリケーション・プログラムの起動を高速化する方法は、高速化プログラム１０８が共有ライブラリ１０９の構造を最適化することにより変換後ライブラリ１１０を作成し、中間コード実行プログラム１０７が従来の共有ライブラリ１０９の代わりに変換後ライブラリ１１０を利用することによりアプリケーション・プログラムの起動時間を短縮するものである。
【００２６】
図２に示されるように、高速化プログラム１０８および中間コード実行プログラム１０７は、コンピュータ１１１の主記憶装置１０２に展開され、実行される。
【００２７】
高速化プログラム１０８は、起動処理監視部１４０１およびライブラリ変換部１４０２を備え、共有ライブラリ１０９からクラスをロードし、アプリケーション・プログラムを実行する。起動処理監視部１４０１は、アプリケーション・プログラムの実行過程において、ロードをおこなったクラスの識別情報とロード順序および過去にロードしたクラスの総数を記憶する。また、アプリケーション・プログラムの起動処理終了箇所を特定する機能を持ち、起動終了と判定するまで上記記憶処理を継続し、起動終了後は上記記憶内容を記憶したプロファイルデータ１４０３を主記憶装置１０２上に記憶する。なお、プロファイルデータ１４０３は、記憶装置１０３上に記憶しても良い。ライブラリ変換部１４０２は起動処理監視部１４０１で出力されたプロファイルデータ１４０３を解析し、共有ライブラリ１０９の構造を最適化した変換後ライブラリ１１０を作成する。
【００２８】
中間コード実行プログラム１０７はクラスロード部１４０４およびベリファイ処理部１４０５を備え、クラスロード部１４０４によって、記憶装置１０３に記憶されている変換後ライブラリ１１０からクラスをロードすることによりアプリケーション・プログラムを実行する。ベリファイ処理部１４０５は、クラスロード部１４０４によってロードされたクラスに対し、その安全性について検証する。この検証作業は複数の段階に分けることができるが、検証のタイミングや検証の有効期間については規定されない。クラスロード部１４０４は変換後ライブラリ１１０を用いることでクラスのロード処理を最適化し、起動時間を短縮できる。
【００２９】
〔実施形態１〕
以下、本発明に係る第一の実施形態について、図３ないし図１１を用いて説明する。
【００３０】
先ず、図３を用いて高速化プログラム１０８がプロファイルデータ１４０３を出力する手順について説明する。
図３は、高速化プログラム１０８がプロファイルデータ１４０３を出力する処理を示したフロー・チャートである。
【００３１】
先ず、高速化プログラム１０８が起動され、アプリケーション・プログラムの実行を指示することでプロファイル処理が開始される（手順２０１）。
【００３２】
指示をおこなう方法として、高速化プログラム１０８のコマンドライン引数に対するアプリケーション・プログラム実行コマンドの明示的な指定、および、ＧＵＩ（Graphic User Interface）またはＣＵＩ（Character User Interface）を利用したユーザ入力による指定などが考えられる。アプリケーション・プログラムの実行が開始されると、次に実行すべき命令が取得される（手順２０２）。
【００３３】
次に、該当命令がアプリケーション・プログラムの起動終了命令であるかが判定される（手順２０３）。起動終了命令は、アプリケーション・プログラムの起動終了箇所を判定するための様々な方式によって呼び出される。起動終了箇所の判定方式として、起動終了箇所にアプリケーション・プログラムの終了コードを挿入する方式、起動終了箇所判定用のＡＰＩを利用する方式、アプリケーション・プログラムで定義される特定の命令、特定のスレッドおよび特定のプロセスの終了を監視する方式、最後のロード処理が発生してから次のロード処理が発生するまでの時間経過を監視する方式、特定のＧＵＩコンポーネントが表示されたかを監視する方式と、ユーザ入力を監視する方式などが考えられる。
【００３４】
アプリケーション・プログラムの該当命令が手順２０３で起動終了命令と判定されなかった場合、該当命令がクラスのロード命令であるかが判定される（手順２０４）。手順２０４でロード命令と判定された場合には、プロファイル処理として、ロードされるクラスの識別情報、ロード順序および過去にロードされたクラスの数が記憶装置１０３上に記憶される（手順２０５）。識別情報は、クラスの絶対パス名など、共有ライブラリ１０９において一意に識別可能な情報である。ただし、手順２０５は手順２０６と並行または手順２０６の後におこなっても良い。
【００３５】
手順２０４によってロード命令と判定されなかった場合、あるいは、手順２０５のプロファイル処理の前後または並行して、該当命令が中間コード実行プログラム１０７と同じインターフェースで実行される（手順２０６）。
【００３６】
手順２０６による命令実行後に、次に実行する命令が取得される（手順２０２）。
【００３７】
一方、手順２０３で起動終了命令と判定された場合には、手順２０５で収集されたプロファイルデータ１４０３をライブラリ変換部１４０２で利用可能な形式に出力される（手順２０７）。プロファイルデータ１４０３の例として、ＣＳＶ形式のテキストデータが挙げられる。そして、プロファイル処理を終了する（手順２０７）。なお、続けて次の手順３０１以下の処理に進んでも良い。
【００３８】
次に、図４ないし図６を用いて共有ライブラリ１０９から変換後ライブラリ１１０に変換する処理を説明する。
図４は、共有ライブラリ１０９から変換後ライブラリ１１０に変換する処理を示したフロー・チャートである。
図５は、ロード順に並べ替えられた変換後ライブラリの構造図である。
図６は、派生的にロードされるクラスを逆順に並べ替えた変換後ライブラリの構造図である。
【００３９】
先ず、共有ライブラリ１０９の変換処理を開始されると（手順３０１）、共有ライブラリ１０９の入力がおこなわれ（手順３０２）、プロファイルデータ１４０３の入力がおこなわれる（手順３０３）。
【００４０】
入力方法としては、高速化プログラムのコマンドライン引数にファイルのパスまたはＵＲＬを指定する方法、ＧＵＩまたはＣＵＩの利用によるユーザ入力によって指定する方法、入力データがファイルでない場合は該当メモリへのポインタを指定する方法などが考えられる。なお、手順３０２と手順３０３は順番が入れ替わっていても良い。
【００４１】
次に、共有ライブラリ１０９内に格納されている起動時に必要なクラス群を起動時のロード順序に並べ変えるかが判定される（手順３０４）。
【００４２】
手順３０４でロード順に変換すると判定された場合には、図５に示されるように、共有ライブラリ１０９内に格納されている起動時に必要なクラス群がプロファイルデータ１４０３に記憶されているロード順序に並べ替えられ、さらに、当該クラス群を先頭から順に格納した変換後ライブラリ１１０へと変換される（手順３０５）。
【００４３】
次に、他クラスのロード処理から派生的にロードされるクラスに関してはロード順序と逆順に並べ替えるかが判定される（手順３０６）。
【００４４】
ここで、派生的にロードされるとは、あるクラスの中でロードする処理が実行されてロードされるクラスであり、これをＪａｖａでは、「派生クラス」といっている。また、二つの方式を指定する方法として、手順３０１で高速化プログラムのコマンドライン引数にフラグを立てる方法、ＧＵＩまたはＣＵＩの利用によるユーザ入力によって指定する方法が考えられる。
【００４５】
派生的にロードされるクラスに関しては逆順に並べ替えると判定された場合、図６に示されるように、共有ライブラリ１０９内に格納されている起動時に必要なクラス群が、派生的にロードされるクラスに関しては逆順に並べ替えられ、さらに、当該クラス群を先頭から順に格納した変換後ライブラリ１１０へと変換される（手順３０５）。
【００４６】
手順３０４および手順３０６で変換方式が指定されなかった場合、共有ライブラリ１０９内に格納されている起動時に必要なクラス群は、変換後ライブラリ１１０の先頭から順に任意の順番で格納される（手順３０８）。変換後ライブラリ１１０は必ずしも新規に作成する必要はなく、共有ライブラリ１０９の構成を変化させるだけでも良い。また、図３に示したプロファイル処理と図４に示したライブラリ変換処理はコンピュータ・プログラムの実行時に並行しておこなっても良い。また、一度目の実行時にプロファイル処理とライブラリ変換処理をおこない、二度目の実行からは変換後ライブラリ１１０を使用する実装も可能である。この場合、一度目の実行時にライブラリの変換処理がおこなわれたことを示すフラグデータを記憶装置１０３に記憶する必要がある。
【００４７】
図５および図６は、変換後ライブラリ１１０の構成を表した図である。
【００４８】
クラス１：４０２は、最初にロードされたクラスであり、クラスＸ：４０３は、起動処理の最後でロードされたクラスである。クラスＸ：４０３以降のクラスは任意の順番で配置され、クラスＮ：４０４は最後に配置されたクラスである。変換後ライブラリ４０１はメタデータ記憶領域４０５を備え、起動に必要なクラスがロード順に格納されていることを表すロード順フラグと、起動に必要なクラスの数Ｘが記憶される。ロード順フラグおよび起動に必要なクラスの数は記憶装置１０３上の任意の場所に記憶することもできるが、特に、メタデータ記憶領域４０５に記憶することで変換後ライブラリ４０１のみを利用した高速化処理が可能となる。
【００４９】
一方、派生的にロードされるクラスに関しては、図６に示されるように該当するクラスを逆順に並べ替える。クラスがロードされる際、当該クラスのロード処理に派生して別のクラスがロードされた場合、この派生的にロードされたクラスを起動時のロード順序とは逆順に並べ替えることで従来発生するはずの派生的なロード処理を省略することができる。クラス２：５０３は、クラス１：５０４から派生的にロードされたクラスであり、クラス３：５０４は、クラス２：５０３から派生的にロードされたクラスである。これらを逆順に並べ替え、それ以外のクラスについてはクラス４：５０５のようにロード順に並べ替える。クラスＸ：５０６は、起動処理の最後にロードされたクラスである。クラスＸ：５０６以降のクラスは、任意の順番で配置され、クラスＮ：５０７は、最後に配置されたクラスを表す。変換後ライブラリ５０１は、図５の変換後ライブラリ４０１と同じくメタデータ記憶領域４０５を備え、派生的にロードされたクラスに関しては逆順に格納されていることを表す逆順フラグと、起動に必要なクラスの数Ｘが記憶される。手順３０８で変換された変換後ライブラリも同様にメタデータ記憶領域４０５を備え、起動に必要なクラスが先頭から順に任意の順序で格納されていることを表すデフォルトフラグと、起動に必要なクラスの個数が記憶される。
【００５０】
次に、図７を用いてアプリケーション・プログラムの起動時に必要なクラスを一括ロードする処理について説明する。
図７は、アプリケーション・プログラムの起動時に必要なクラスを一括ロードする処理を示したフローチャートである。
【００５１】
本発明は、変換後ライブラリ１１０を利用することで、起動時に必要となるクラス群を容易に特定でき、当該クラスに限定した最適化を施すことができる。この最適化されたライブラリを最大限に利用するために、実行されるアプリケーション・プログラムの実行開始時において、アプリケーション・プログラムの起動時にロードされるクラスに限定して一度に全てのクラスをロードする一括ロード命令をおこなう処理が考えられる。これにより、実行時の要求に応じてクラスをロードするロード命令（以下、「要求駆動型ロード命令」という）を省略でき、さらにクラスの検索処理も省略できる。
【００５２】
先ず、アプリケーション・プログラムの実行が開始されると（手順６０１）、順次命令が取得され（手順６０２）、当該命令が一括ロード命令であるかが判定される（手順６０３）。一括ロード命令は、クラスロード部１４０４で定義される命令として明示的に呼び出されるか、または、クラスロード部１４０４で最初に実行されるロード命令の中から呼び出される。当該命令が一括ロード命令である場合にはアプリケーション・プログラムの実行に必要な共有ライブラリがリストアップされる（手順６０４）。共有ライブラリのリストを指定する方法としては、例えば、手順６０１でアプリケーション・プログラム実行開始時にコマンドライン引数として指定する方法と、ＧＵＩまたはＣＵＩの利用によるユーザ入力によって指定する方法がある。次に、リストアップされた共有ライブラリの先頭に位置するライブラリがピックアップされ（手順６０４）、当該ライブラリが変換後ライブラリ１１０であるか否かが判定される（手順６０６）。判定方式として、当該ライブラリのメタデータ記憶領域４０５または記憶装置１０３上に立てられたフラグを用いる。当該ライブラリが変換後ライブラリ１１０であった場合、手順６０７で変換後ライブラリ１１０のメタデータ記憶領域４０５または記憶装置１０３上から起動に必要なクラスの個数を読み込み（手順６０７）、一括ロード処理が実行される（手順６０８）。
【００５３】
次に、手順６０６で当該ライブラリが変換後ライブラリ１１０と判定されなかった場合、また、手順６０８で一括ロード命令を実行した後に、未処理のライブラリがリストに残っているかが判定される（手順６０９）。未処理のライブラリが残っている場合、次の共有ライブラリへ処理を移し（手順６１０）、未処理の共有ライブラリが無くなるまで処理が繰り返し実行される。未処理の共有ライブラリが無くなると、次の命令を呼び出され（手順６０２）、アプリケーション・プログラムの実行が継続される。手順６０３で一括ロード命令と判定されなかった場合には、当該命令が実行され（手順６１１）、次の命令へと移行する（手順６０２）。アプリケーション・プログラムの終了命令が実行された場合には、アプリケーション・プログラムの実行を終了する。
【００５４】
次に、図８を用いて図７の手順６０８における一括ロード処理の詳細を説明する。
図８は、図７の手順６０８における一括ロード処理の詳細な処理を示したフローチャートである。
【００５５】
先ず、起動に必要なクラスが全てロードされたかが判定され（手順７０１）、ロードされていない場合には、次のロード対象クラスに処理が移行される（手順７０２）。そして、クラスがすでにロード済であるか否かが判定され（手順７０２）、ロード済でなければクラスのロード処理がおこなわれる（手順７０４）。手順７０３でクラスがロード済であった場合には、あるいは、手順７０４でクラスのロード処理をおこなった後は手順７０１に戻り、起動に必要なクラスが全てロードされるまで処理を繰り返す。この方式では変換後ライブラリ１１０の変換方法は関係なく、全ての変換後ライブラリ１１０に適用できる。
【００５６】
次に、図９を用いて手順６０８の一括ロード処理において、派生的にロードされるクラスが存在する場合の処理について説明する。
【００５７】
図９は、手順６０８の一括ロード処理において、派生的にロードされるクラスが存在する場合の処理を示したフローチャートである。
【００５８】
これはオブジェクト指向言語のプログラムにおいて、子クラスのロードによって派生的に親クラスがロードされる場合などが例として挙げられる。この場合、派生的にロードされるクラスに関してはロード順序と逆順に変換後ライブラリ１１０へ格納することで、従来発生するはずの派生的なロード処理を省略することができる。
【００５９】
先ず、変換後ライブラリ１１０のメタデータ記憶領域４０５または記憶装置１０３から変換後ライブラリ１１０の逆順フラグが判定され（手順８０１）、逆順フラグがＯＦＦの場合には、通常の一括ロード処理と同様に目的のクラスがロードされ（手順８０２〜手順８０５）、派生的にロードされるクラスが存在するか否かが判定される（手順８０６）。手順８０６で派生的にロードされるクラスが存在すると判定された場合、派生クラスのロード処理がおこなわれ（手順８０７）、以後、全ての派生クラスがロードされたと判定されるまで（手順８０８）、ロード処理を繰り返す。
【００６０】
一方、手順８０１で逆順フラグがＯＮの場合、図８の一括ロード処理と同様にクラスがロードされる（手順７０１〜手順７０４）。派生的にロードされるクラスは派生元（ロード元）となるクラスよりも前にロードされていることが保証されているため、当該クラスのロード処理を省略することができ、起動時間を短縮することができる。
【００６１】
次に、図１０および図１１を用いて手順６０８の一括ロード処理において、ベリファイ処理をおこなう場合について説明する。
図１０は、一括ロード処理において、ベリファイ処理をおこなう場合の処理を示したフロー・チャートである。
図１１は、プログラム実行時におけるベリファイ処理の詳細な処理を示したフローチャートである。
【００６２】
上記の記述では、アプリケーション・プログラムの起動を高速化するために、プログラムライブラリを変換する方法を説明してきた。
【００６３】
ここでは、それに加えて安全性を保証するためのベリファイ処理おこなう場合な関連する方法について説明する。すなわち、変換後ライブラリ１１０を利用した一度目のアプリケーション・プログラム実行時にベリファイ処理をおこない、二度目の実行からはベリファイ処理を省略することで起動時間を短縮するものである。アプリケーション・プログラムが二度目の実行であることを判定するため、中間コード実行プログラム１０７は、記憶装置１０３上にベリファイ済フラグを立てる。
【００６４】
この手順では、先ず、ベリファイ済フラグが判定され（手順９０１）、ベリファイ済フラグがＯＦＦの場合には、図７の一括ロード処理と同様にクラスがロードされ（手順９０２から手順９０５）、ベリファイ処理が実行される（手順９０６）。このベリファイ済フラグは、起動時のベリファイ処理をおこなったことを示すフラグである。
【００６５】
クラスがロード済と判定された場合も（手順９０４）、同様にベリファイ処理を実行する（手順９０６）。
【００６６】
これはクラスがロード済であっても、ベリファイ処理はロードされたときよりも後に実行させることがあるため、ベリファイ処理を確実に実行するために必要な手順である。起動に必要な全てのクラスがロード済と判定されると（手順９０２）、ベリファイ済フラグがＯＮに変更される（手順９０７）。
【００６７】
以後、二度目の実行時には、ベリファイ済フラグがＯＮと判定され（手順９０１）、クラスのロード処理をおこなった後（手順９０８から手順９１１）、ロード時に発生するベリファイ処理を省略できる（手順９１２）。また、そのクラスがベリファイされたことを示すベリファイ省略フラグをＯＮにする。このベリファイ省略フラグは、一つ一つのクラスに対して定義され、そのクラスのベリファイ処理が省略できるか否かを示すフラグである。
【００６８】
図１１に示されるように、ベリファイ命令は、アプリケーション・プログラムの実行開始から任意のタイミングで発生する。
【００６９】
アプリケーション・プログラムの実行が開始されると（手順１００１）、順次命令が取得され（手順１００２）、ベリファイ省略フラグの判定がおこなわれる（手順１００４）。ベリファイ省略フラグがＯＮの場合、ベリファイ処理は省略され（手順１００５）、次の命令に移行する。ベリファイ省略フラグがＯＦＦの場合、ベリファイ処理が実行される（手順１００６）。手順１００３でベリファイ命令と判定されなかった場合は、通常通り命令が実行され（手順１００７）、次の命令へと移る。そして、手順１００７でアプリケーション・プログラムの終了命令が実行されると、アプリケーション・プログラムは終了する。
【００７０】
こうしてベリファイ省略フラグを利用することで、任意のタイミングで発生するベリファイ処理を省略できる。
【００７１】
また、上記一括ロード命令の実行は別のスレッドおよびプロセスで実行することもできる。起動処理とロード処理を並行して実行することで、起動時間が短縮される可能性がある。さらに、クラスのロード時において、起動に必要なライブラリ群が格納されている変換後ライブラリ１１０の該当部分を記憶装置１０３よりも高速な主記憶装置１０２上に展開し、ディスク入出力の回数を減らすことで起動時間を短縮できる可能性がある。
【００７２】
〔実施形態２〕
以下、本発明に係る第二の実施形態について、図１２ないし図１４を用いて説明する。
【００７３】
第一の実施形態は、変換後ライブラリ１１０を利用し、起動時に一括ロードをおこなうことにより、アプリケーション・プログラムの起動の高速化を図るものであった。本実施形態は、変換後ライブラリ１１０を利用し、実行時の要求に応じて個別にクラスをロードする要求駆動型ロード処理の場合の例である。
図１２は、アプリケーション・プログラムの実行に際して、実行時の要求に応じて個別にクラスをロードする要求駆動型ロード処理を示したフローチャートである。
図１３は、手順１１１０のロード処理の詳細な処理を示したフロー・チャートである。
図１４は、要求駆動型ロード処理の場合におけるロード処理にベリファイ処理をおこなう場合の処理を示したフロー・チャートである。
【００７４】
ここで要求駆動型ロード処理は中間コード実行プログラム１０７で定義された個別ロード命令によっておこなわれるものとする。
【００７５】
中間コード実行プログラム１０７によってアプリケーション・プログラムの実行が開始されると（手順１１０１）、順次命令が取得される（手順１１０２）。当該命令が個別ロード命令と判定されると（手順１１０３）、ロード対象のクラスがすでにロード済であるかが判定される（手順１１０４）。当該クラスがロード済であった場合、または、当該命令が個別ロード命令でなかった場合には、当該命令が実行され（手順１１１２）、次の命令が呼び出される（手順１１０２）。目的のクラスがロード済でなかった場合、検索対象となるライブラリがリストアップされ（手順１１０５）、先頭のライブラリに対する処理が開始される（手順１１０６）。
【００７６】
そして、当該ライブラリが変換後ライブラリ１１０であると判定された場合（手順１１０７）、起動に必要なクラスの数が取得され（手順１１０８）、起動に必要なクラスが全てロードされたか否かが判定され（手順１１０９）、全てのクラスがロードされていない場合には、クラスのロード処理を実行する（手順１１１０）。手順１１０９で起動に必要なクラスが全てロードされたと判定された場合、または、当該ライブラリが変換後ライブラリ１１０ではないと判定された場合（手順１１０７）には、通常の個別ロード命令を実行する（手順１１１３）。目的のクラスがロードされず（手順１１１１および手順１１１４）、かつ、検索対象のライブラリが残っている場合には（手順１１１５）、次の検索対象ライブラリに処理対象が移行され（手順１１１６）、検索対象ライブラリが全て無くなるか、または目的のクラスがロードされるまで処理が続けられる。そして、手順１１１２でアプリケーション・プログラムの終了命令が実行されるとアプリケーション・プログラムが終了する。
【００７７】
手順１１１０のロード処理は、図１３に示され如くおこなわれる。
【００７８】
先ず、変換後ライブラリ１１０のメタデータ記憶領域４０５または記憶装置１０３からロード順フラグの判定をおこない（手順１２０１）、ロード順フラグがＯＮであれば先頭から順にロード対象となるクラスを検出する。フラグがＯＦＦの場合、クラスの検索処理をおこなう（手順１２０３）。ここでおこなう検索処理は、変換後ライブラリ１１０全体を対象にする必要はなく、起動時に必要なクラスに限定しておこなうことができる。当該クラスが目的のクラスであると判定された場合（手順１２０４）、クラスのロード処理をおこなう（手順１２０５）。目的のクラスでないと判定された場合、または、手順１２０５でクラスのロード処理が終了した場合、手順１１１１へ移行する。このように、要求駆動型ロード処理の場合であっても、変換後ライブラリ１１０をロード順に配置することで、クラスの検索処理を省略し、起動時間を短縮できる。また、ロード順に並んでいない場合も検索対象となるクラスの数を減らすことができる。
【００７９】
また、手順１２０５のロード処理においてベリファイ処理部１４０５が有効な場合には、図１４に示される処理がおこなわれる。
【００８０】
先ず、変換後ライブラリ１１０のメタデータ記憶領域４０５または記憶装置１０３からベリファイ済フラグの判定をおこない（手順１３０１）、ベリファイ済フラグがＯＮと判定された場合、クラスをロードし（手順１３０２）、ベリファイ処理を省略し（手順１３０３）、ベリファイ省略フラグをＯＮにする（手順１３０４）。ベリファイ省略フラグをＯＮにすることで、図１１で説明した任意のタイミングで実行されるベリファイ処理を省略できる。手順１３０１でベリファイ済フラグがＯＦＦと判定された場合、クラスをロードし（手順１３０５）、ベリファイ処理を実行する（手順１３０６）。起動に必要なクラスが全てロードされたと判定された場合（手順１３０７）、ベリファイ済フラグをＯＮにする（手順１３０８）。ベリファイ済フラグがＯＮになると、二度目のアプリケーション・プログラム実行時からはベリファイを省略することができ、起動時間を短縮することができる。
【図面の簡単な説明】
【００８１】
【図１】本発明の一実施形態に係るコンピュータシステムの構成図である。
【図２】本発明のアプリケーション・プログラムの起動を高速化するためのプログラム制御方法の処理の概要を示す図である。
【図３】高速化プログラム１０８がプロファイルデータ１４０３を出力する手順を表したフロー・チャートである。
【図４】共有ライブラリ１０９から変換後ライブラリ１１０に変換する処理を表したフロー・チャートである。
【図５】ロード順に並べ替えられた変換後ライブラリの構造図である。
【図６】派生的にロードされるクラスを逆順に並べ替えた変換後ライブラリの構造図である。
【図７】アプリケーション・プログラムの起動時に必要なクラスを一括ロードする処理を表したフローチャートである。
【図８】図７の手順６０８における一括ロード処理の詳細を表したフロー・チャートである。
【図９】手順６０８の一括ロード処理において、派生的にロードされるクラスが存在する場合の処理を示したフローチャートである。
【図１０】一括ロード処理において、ベリファイ処理をおこなう場合を示したフロー・チャートである。
【図１１】プログラム実行時におけるベリファイ処理の詳細な手順を示したフローチャートである。
【図１２】アプリケーション・プログラムの実行に際して、実行時の要求に応じて個別にクラスをロードする要求駆動型ロード処理を表したフローチャートである。
【図１３】手順１１１０のロード処理の詳細を表したフロー・チャートである。
【図１４】要求駆動型ロード処理の場合におけるロード処理にベリファイ処理をおこなう場合を表したフロー・チャートである。
【符号の説明】
【００８２】
１０１…演算装置
１０２…主記憶装置
１０３…記憶装置
１０４…入力装置
１０５…出力装置
１０６…通信装置
１０７…中間コード実行プログラム
１０８…高速化プログラム
１０９…共有ライブラリ
１１０…変換後ライブラリ
１１１…コンピュータ
４０１…ロード順変換後ライブラリ
５０１…逆順変換後ライブラリ
１４０１…起動処理監視部
１４０２…ライブラリ変換部
１４０３…プロファイルデータ
１４０４…クラスロード部
１４０５…ベリファイ処理部。
【図１】
2006350489.tif 000003
【図２】
2006350489.tif 000004
【図３】
2006350489.tif 000005
【図４】
2006350489.tif 000006
【図５】
2006350489.tif 000007
【図６】
2006350489.tif 000008
【図７】
2006350489.tif 000009
【図８】
2006350489.tif 000010
【図９】
2006350489.tif 000011
【図１０】
2006350489.tif 000012
【図１１】
2006350489.tif 000013
【図１２】
2006350489.tif 000014
【図１３】
2006350489.tif 000015
【図１４】
2006350489.tif 000016