(57)【要約】【課題】シンボル検索時のハッシュテーブル検索回数や文字列比較回数を削減し、ランタイムリンカにおけるバインド処理のオーバヘッドを削減すること。【解決手段】共有ライブラリ内のｉｍｐｏｒｔシンボルからｅｘｐｏｒｔシンボルへのポインタを形成したシンボルテーブルをプロセス間で共有する。テーブルが共有されているかを判別し、共有されていれば形成したポインタによりｅｘｐｏｒｔシンボルを得る。また、バインド処理を行ったあとのデータ領域の一部または全体をあらかじめ保存しておく。保存した時点からプログラムや依存ライブラリに変更がなければ、ロードアドレスが保存時と異なっていれば再配置処理を行ったのち、保存したのデータ領域をコピーする。【選択図】                図２
2004151822.tif 000002
【特許請求の範囲】
【請求項１】
プログラムから参照される共有ライブラリ内のシンボルのアドレスまたは他の共有ライブラリから参照される共有ライブラリ内のシンボルのアドレスを該プログラムまたは該他の共有ライブラリに埋め込む共有ライブラリのバインド方法において、
すべてまたは一部の前記共有ライブラリに対して、シンボルを管理するエントリをシンボル識別子順に配置したシンボルテーブルをそれぞれ作成するステップと、
前記シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリ（以下、エントリＡという）から、前記ｉｍｐｏｒｔシンボルと名称の等しいｅｘｐｏｒｔシンボルを管理するシンボルテーブルのエントリへのポインタを形成するステップと、
前記共有ライブラリの該ポインタを形成したシンボルテーブルと、該シンボルテーブルと組をなし識別情報を有するライブラリ管理テーブルとを複数のプロセス間で共有するステップと、
前記ｉｍｐｏｒｔシンボルを管理するエントリが属する前記シンボルテーブルが共有されているか否かを、前記ライブラリ管理テーブルの識別情報の有無により識別するステップと、
共有されている場合に、前記シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリＡの前記ポインタが示すエントリ（以下、エントリＢという）が管理するシンボルが属するライブラリ（以下、ライブラリＢという）がロード済であり、かつ前記ライブラリＢより検索優先順位の高いライブラリに同じ名称のｅｘｐｏｒｔシンボルが見つからなければ、前記エントリＢのシンボルを前記ｉｍｐｏｒｔシンボルにバインドするステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項２】
請求項１記載の共有ライブラリのバインド方法において、
前記シンボルテーブルと該シンボルテーブルと組をなし識別情報を有するライブラリ管理テーブルとをあらかじめ指定した範囲内の領域に割り当て、前記領域の仮想記憶管理テーブルのフラグを設定するステップと、
該フラグの状態をチェックし、該フラグが設定されていれば前記仮想記憶管理テーブルとページテーブルとを複製するステップと、
前記プログラムをロードするとき、該プログラムを実行するプロセスに前記仮想記憶管理テーブルとページテーブルとを複製するステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項３】
請求項１記載の共有ライブラリのバインド方法において、
前記共有ライブラリのローディング回数を記録するステップと、
前記ローディング回数の多い順に前記共有ライブラリの前記シンボルテーブルを共有するステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項４】
請求項１記載の共有ライブラリのバインド方法において、
名称の異なるシンボルごとに、一意の識別子を与えるステップと、
前記識別子ごとのエントリを有するテーブル（以下、テーブルＧという）を設けるステップと、
前記ライブラリのいずれかのライブラリ（以下、ライブラリＣという）内のグローバルオフセットテーブルに前記ｉｍｐｏｒｔシンボルに対してバインドした前記ｅｘｐｏｒｔシンボルのアドレスを埋め込んだとき、該アドレスを、前記テーブルＧ内の該ｉｍｐｏｒｔシンボルに与えられた識別子に対応したエントリに登録するステップと、
前記ｉｍｐｏｒｔシンボルと名称の一致する、前記ライブラリのいずれかのライブラリ（以下、ライブラリＤという）内の前記ｅｘｐｏｒｔシンボルを検索する前に前記テーブルＧのエントリを参照するステップと、
前記テーブルＧのエントリに前記アドレスが代入されていれば、前記ライブラリ内のシンボルを検索せずに前記代入されているアドレスを前記ライブラリＤのグローバルオフセットテーブルに埋め込むステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項５】
請求項１記載の共有ライブラリのバインド方法において、
検索する必要があり、かつ検索条件の等しい前記シンボルテーブル内のエントリのキューを形成するステップと、
同じ検索方法を用いて前記キュー内のエントリのみを検索するステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項６】
プログラムから参照される共有ライブラリ内のシンボルのアドレスまたは他の共有ライブラリから参照される共有ライブラリ内のシンボルのアドレスを該プログラムまたは該他の共有ライブラリに埋め込む共有ライブラリのバインド方法において、
前記共有ライブラリの最終更新日時と、バインド後のデータ領域と、前記プログラムおよび前記共有ライブラリの先頭アドレスと、前記データ領域のアドレスと、をファイルに保存するステップと、
前記共有ライブラリと前記ファイルとをロードするステップと、
前記最終更新日時とロードされた前記共有ライブラリの最終更新日時とを比較するステップと、
前記先頭アドレスとロードされた前記共有ライブラリの先頭アドレスとを比較するステップと、
前記最終更新日時が一致し、かつ前記先頭アドレスが一致していれば、前記データ領域をロードされた前記共有ライブラリのデータ領域に複写するステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項７】
プログラムから参照される共有ライブラリ内のシンボルのアドレスまたは他の共有ライブラリから参照される共有ライブラリ内のシンボルのアドレスを該プログラムまたは該他の共有ライブラリに埋め込む共有ライブラリのバインド方法において、
前記共有ライブラリの最終更新日時と、バインド後のデータ領域と、前記プログラムおよび前記共有ライブラリの先頭アドレスと、前記データ領域のアドレスと、をファイルに保存するステップと、
前記共有ライブラリと前記ファイルとをロードするステップと、
前記最終更新日時とロードされた前記共有ライブラリの最終更新日時とを比較するステップと、
前記先頭アドレスとロードされた前記共有ライブラリの先頭アドレスとを比較するステップと、
前記最終更新日時が一致し、前記先頭アドレスが一致していなければ、前記データ領域内のアドレスをロードされた前記共有ライブラリのアドレスにあわせて再配置するステップと、
再配置した前記データ領域をロードされた前記共有ライブラリのデータ領域に複写するステップと、
を含むことを特徴とする共有ライブラリのバインド方法。
【請求項８】
プログラムから参照される共有ライブラリ内のシンボルのアドレスまたは他の共有ライブラリから参照される共有ライブラリ内のシンボルのアドレスを該プログラムまたは該他の共有ライブラリに埋め込むためのプログラムであって、
すべてまたは一部の前記共有ライブラリに対して、シンボルを管理するエントリをシンボル識別子順に配置したシンボルテーブルをそれぞれ作成する手順と、前記シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリ（以下、エントリＡという）から、前記ｉｍｐｏｒｔシンボルと名称の等しいｅｘｐｏｒｔシンボルを管理するシンボルテーブルのエントリへのポインタを形成する手順と、
前記共有ライブラリの該ポインタを形成したシンボルテーブルと、該シンボルテーブルと組をなし識別情報を有するライブラリ管理テーブルとを複数のプロセス間で共有する手順と、
前記ｉｍｐｏｒｔシンボルを管理するエントリが属する前記シンボルテーブルが共有されているか否かを、前記ライブラリ管理テーブルの識別情報の有無により識別する手順と、
識別の結果、共有されている場合に、前記シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリＡの前記ポインタが示すエントリ（以下、エントリＢという）が管理するシンボルが属するライブラリ（以下、ライブラリＢという）がロード済であり、かつ前記ライブラリＢより検索優先順位の高いライブラリに同じ名称のｅｘｐｏｒｔシンボルが見つからなければ、前記エントリＢのシンボルを前記ｉｍｐｏｒｔシンボルにバインドする手順を実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に計算機システムのプログラムローディング方法に関し、特に、ランタイムリンカにおける共有ライブラリのシンボル検索・バインド処理の高速化に関する。
【０００２】
【従来の技術】
プログラムから呼び出される関数を集めた共有ライブラリのコードやデータを、プログラムをロードする時や必要とされるときにランタイムリンカを呼び出し動的にリンクする技術がある。
ランタイムリンカでは、プログラム中のポインタをオフセットから絶対アドレスに変換するリロケーション処理や、バインド処理が行われる。
バインド処理では、プログラムまたはプログラムが参照する共有ライブラリから参照される依存共有ライブラリ内のｉｍｐｏｒｔシンボル（外部の関数または変数への参照）に対するｅｘｐｏｒｔシンボル（外部から参照される関数または変数の定義）を検索し、ｅｘｐｏｒｔシンボルのアドレスを、ｉｍｐｏｒｔシンボルの属するライブラリのグローバルオフセットテーブル（外部変数や関数の絶対アドレスを保持するテーブル）に埋め込む。
【０００３】
ｉｍｐｏｒｔシンボルに対するｅｘｐｏｒｔシンボルを検索する第１の方法として、ライブラリのオブジェクトファイルに格納されたハッシュテーブルとシンボルテーブルを利用する方法がある。
ハッシュテーブルの各エントリには、文字列を変換したハッシュ値をｂｕｃｋｅｔ数で割った剰余が等しい次のシンボルテーブルエントリのインデックス番号が格納されている。
最初にロードされたライブラリのハッシュテーブルのキューをたどり、各キューのエントリ内に記載されたインデックス番号のシンボルテーブルエントリの名称をｉｍｐｏｒｔシンボル名称と比較する。
みつからなければ次にロードされたライブラリのハッシュテーブルのキューをたどる。
【０００４】
ｉｍｐｏｒｔシンボルに対するｅｘｐｏｒｔシンボルを検索する第２の方法として、グローバルシンボルテーブルを利用する方法がある。
プログラムをロードしたとき、あらかじめロードされた全ライブラリのｅｘｐｏｒｔシンボルをグローバルシンボルテーブルのハッシュテーブルに登録しておく。
第１の方法と同様にハッシュテーブルからｉｍｐｏｒｔシンボル名称と一致するエントリを探すが、複数のハッシュテーブルをさがすことはしない。
【０００５】
ｉｍｐｏｒｔシンボルに対するｅｘｐｏｒｔシンボルを検索する第３の方法として、リロケーション済みのプログラム全体またはライブラリのキャッシングを利用する方法がある。
プログラム全体がキャッシュされていればコピーして使う。
プログラムとその依存ライブラリのうち依存ライブラリのみがキャッシュされている場合は、プログラムのｅｘｐｏｒｔシンボルが、依存ライブラリ内にも存在するかチェックする。
存在すればそのシンボルのリロケーションをし直す。
チェックする方法は、第１または第２の方法を用いる。
【０００６】
【発明が解決しようとする課題】
従来の技術に記載の方法のうち、第１の方法では、ライブラリごとにハッシュテーブル内をサーチするため、ライブラリ数やライブラリ内のシンボル数が増えるほど、ハッシュテーブル数・検索エントリ数・文字列比較回数が増加するという問題がある。
第２の方法では、検索するハッシュテーブルは１つですむが、シンボル数がふえるほど同一キュー内のエントリ数が増加し、ｉｍｐｏｒｔシンボルに対するｅｘｐｏｒｔシンボルを検索するときの検索エントリ数・文字列比較回数、ｅｘｐｏｒｔシンボルの登録回数が増加するという問題がある。
第３の方法では、一部のライブラリのみがキャッシングされている場合は、プログラム内のｅｘｐｏｒｔシンボルのほかに、キャッシングされていないライブラリのｅｘｐｏｒｔシンボルもチェックしなければならず、検索エントリ数が増加するという問題がある。
また、プログラム全体をキャッシュする場合は、メモリ使用量が増加するという問題がある。
本発明では、シンボルの検索エントリ数を削減することにより、ランタイムリンカにおけるバインド処理を高速化することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的達成のため、本発明の共有ライブラリのバインド方法は、すべてまたは一部の共有ライブラリに対して、シンボルを管理するエントリをシンボル識別子順に配置したシンボルテーブルをそれぞれ作成するステップと、シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリＡから、ｉｍｐｏｒｔシンボルと名称の等しいｅｘｐｏｒｔシンボルを管理するシンボルテーブルのエントリへのポインタを形成するステップと、共有ライブラリの該ポインタを形成したシンボルテーブルと、該シンボルテーブルと組をなし識別情報を有するライブラリ管理テーブルとを複数のプロセス間で共有するステップと、ｉｍｐｏｒｔシンボルを管理するエントリが属する前記シンボルテーブルが共有されているか否かを、ライブラリ管理テーブルの識別情報の有無により識別するステップと、共有されている場合に、シンボルテーブルのｉｍｐｏｒｔシンボルを管理するエントリＡの前記ポインタが示すエントリＢが管理するシンボルが属するライブラリＢがロード済であり、かつライブラリＢより検索優先順位の高いライブラリに同じ名称のｅｘｐｏｒｔシンボルが見つからなければ、エントリＢのシンボルをｉｍｐｏｒｔシンボルにバインドするステップとを有する。
また、共有ライブラリの最終更新日時と、バインド後のデータ領域と、前記プログラムおよび前記共有ライブラリの先頭アドレスと、前記データ領域のアドレスとをファイルに保存するステップと、共有ライブラリと前記ファイルとをロードするステップと、前記最終更新日時とロードされた前記共有ライブラリの最終更新日時とを比較するステップと、前記先頭アドレスとロードされた前記共有ライブラリの先頭アドレスとを比較するステップと、前記最終更新日時が一致し、かつ前記先頭アドレスが一致していれば、前記データ領域をロードされた前記共有ライブラリのデータ領域に複写するステップとを有する。
【０００８】
【発明の実施の形態】
以下、本発明の一実施形態を図面を参照して詳細に説明する。
図１は、本発明を実施するシステムのハードウェア構成の一例を示した図である。
図１において、１００は本発明が実施される計算機システムであり、中央処理装置１０１、主記憶装置１０２、入出力装置１０３が含まれる。
主記憶装置１０２には、プログラム３０１や、１つないし複数のプログラム３０１または他の共有ライブラリから呼び出される関数や参照されるデータが格納されている１つないし複数の共有ライブラリ３００（以下、ライブラリ３００という）や、ライブラリ３００のロード・リロケーション・バインド処理を行うランタイムリンカ７００（以下、リンカ７００という）、のコードやデータが存在する。
これらのコードは、プログラムの実行が要求されたとき、入出力装置１０３から読み込まれ、さらに中央処理装置１０１にロードされ実行される。
また、主記憶装置１０２には、データ領域保存処理５００と共有テーブル作成処理６００も含まれる。
処理５００と処理６００は、中央処理装置１０１にロードされ実行される。
プログラム３０１やライブラリ３００内には、関数やデータのアドレスを格納するグローバルオフセットテーブル３４０や、共有ライブラリ３００内で定義された関数およびデータ（ｅｘｐｏｒｔシンボル）や共有ライブラリ内から参照する他の共有ライブラリ内の関数およびデータ（ｉｍｐｏｒｔシンボル）を管理するシンボルテーブル３２０が含まれる。
【０００９】
主記憶装置１０２には、複数のプロセス１１１が含まれ、プロセスごとに仮想記憶空間が割り当てられる。
ページテーブル１１２によって仮想記憶空間内の領域と主記憶装置の領域とのマッピングが管理され、仮想記憶管理テーブル１２０によって仮想記憶空間内の領域の利用状態が管理される。
プログラム３０１・ライブラリ３００・リンカ７００は、通常プロセスごとに存在するが、複数のプロセスで共有してもよい。
複数のプロセスで共有するものとして、共有テーブル２００が主記憶装置内に含まれる。
リンカ７００のバインド処理では、シンボルテーブル３２０と共有テーブル２００を参照し、グローバルオフセットテーブル３４０内にアドレスを格納する。また、入出力装置１０３には、バインド情報保存ファイル４００や共有設定ファイル１５０が含まれる。
バインド情報保存ファイル４００は、主記憶装置１０２に読み込まれ、グローバルオフセットテーブル３４０の復元に利用される。
共有設定ファイル１５０は、共有テーブル２００に登録するライブラリ３００を決定するために使用される。
また、各プロセス１１１には、バインドアドレス保存テーブル１３０が割り当てられ、検索済のｅｘｐｏｒｔシンボルのアドレスを記憶するために利用されるが、バインドアドレス保存テーブル１３０はなくてもよい。
【００１０】
図２に、本発明の全体のフローチャート図を示す。
事前にコマンドなどの手段により処理５００を起動し、リンカ７００と同様にロード・リロケーション・バインドを行った後、グローバルオフセットテーブル３４０内の情報を含んだバインド情報をファイル４００に保存し、ライブラリ３００の初期化や実行を行わずに終了する。詳細は後述する。
また、計算機起動後に、処理６００を実行する。
処理６００では、共有テーブル２００を作成し、他のプロセスが利用できるようにする。詳細は後述する。
リンカ７００では、プロセス内に共有テーブル２００を割り当てて参照可能にし、プログラム３０１をロードしたのち、ファイル４００が利用可能かどうか調べ、利用可能であれば、バインド情報保存ファイル４００内の情報をもとに、データ領域のグローバルオフセットテーブル３４０等に埋め込んだアドレスを復元する。
利用不可能な場合は、シンボルテーブル３２０と共有テーブル２００の情報を用いてバインド処理を行う。詳細は後述する。
本発明では、バインドを高速化するための情報を付加した共有テーブル２００をプロセス間で共有し、シンボルテーブル３２０と併用してバインド処理に利用するところと、バインド情報保存ファイル４００内の情報をもとにデータ領域に埋め込んだアドレスを復元するところに特徴がある。
【００１１】
まず、処理５００の実施方法を詳細に説明する。
図３に、ライブラリ３００の構造を示す。
プログラム３０１の構造も図３と同じである。
ライブラリ３００には、前述のシンボルテーブル３２０、グローバルオフセットテーブル３４０のほか、ハッシュテーブル３１０やリロケーションテーブル３３０が含まれる。
グローバルオフセットテーブル３４０には、ライブラリ３００内で定義されたデータのアドレスやライブラリ３００から参照されるデータのアドレスを格納する領域３４１が含まれる。
なお、ライブラリ３００およびプログラム３０１のプログラムコードについては図３では図示を省略している。
【００１２】
図４に、テーブル３１０〜３３０の構造を示す。
シンボルテーブル３２０の各エントリ３２１には、シンボル名３２２、関数やデータのモジュール内オフセットであるシンボル値３２３、シンボルが定義されているセクションの識別番号３２４が含まれる。なお、プログラムやライブラリのオブジェクトコードの各構成要素ないし領域をセクションという。
ハッシュテーブル３１０はバケット（ｂｕｃｋｅｔ）３１１とチェイン（ｃｈａｉｎ）３１２から構成される。
ｃｈａｉｎ３１２は、シンボルテーブル３２０のエントリ３２１の総数に等しい数のエントリをもつ。
各エントリ３２１に対してシンボルテーブル３２０内で一意の順序番号を与え、この順序番号をエントリ３２１のシンボル識別子ｓｙｍｉｄｘ（以下、識別子ｓｙｍｉｄｘ）とする。
シンボルのシンボル名３２２を変換関数を用いてハッシュ値に変換する。
ハッシュ値をｂｕｃｋｅｔ３１１のエントリ数で割った剰余を求める。
ｂｕｃｋｅｔ［０］はこの剰余が‘０’であるｂｕｃｋｅｔ３１１のエントリであり、ｂｕｃｋｅｔ［１］はこの剰余が‘１’であるｂｕｃｋｅｔ３１１のエントリである。
【００１３】
図４の例の場合を用いて説明すると、ｃｈａｉｎ３１２の最上欄のエントリには、上記の剰余が‘０’であるエントリ３２１の識別子ｓｙｍｉｄｘの１つを格納し、ｂｕｃｋｅｔ［０］のエントリにはこのｃｈａｉｎ３１２の最上欄のエントリを指し示すポインタを格納し、ｃｈａｉｎ３１２の最上欄のエントリには上記の剰余が‘０’である他の識別子ｓｙｍｉｄｘが格納されているｃｈａｉｎ３１２の他のエントリを指し示すポインタを格納し、以下同様にして上記の剰余が‘０’である識別子ｓｙｍｉｄｘのキューを形成する。
また、ｂｕｃｋｅｔ［１］のエントリには上記の剰余が‘１’であるエントリ３２１の識別子ｓｙｍｉｄｘの１つが格納されているｃｈａｉｎ３１２のエントリを指し示すポインタを格納し、このｃｈａｉｎ３１２のエントリには上記の剰余が‘１’である他の識別子ｓｙｍｉｄｘが格納されているｃｈａｉｎ３１２の他のエントリを指し示すポインタを格納する。以下同様にして上記の剰余が‘１’である識別子ｓｙｍｉｄｘのキューを形成する。
さらに同様にして、ｂｕｃｋｅｔ［２］、ｂｕｃｋｅｔ［３］、・・・に関する識別子ｓｙｍｉｄｘのキューを形成することにより、ｃｈａｉｎ３１２におけるキューを形成する。ｃｈａｉｎ３１２の各エントリは、ｓｙｍｉｄｘのほかに、ハッシュ値を含んでいてもよい。
リロケーションテーブル３３０の各エントリ３３１には、バインドするｉｍｐｏｒｔシンボルの識別子３３２や、ｉｍｐｏｒｔシンボルに対するｅｘｐｏｒｔシンボルのアドレスを格納するグローバルオフセットテーブル３４０の領域３４１のライブラリ先頭からのオフセット３３３が含まれる。
【００１４】
図５に、バインド情報保存ファイル４００の構造を示す。
バインド情報保存ファイル４００には、１つないし複数のバインド情報４１０が含まれる。
バインド情報４１０は、プログラム３０１に対して１つ、プログラム３０１をロードしたときにリンカ７００によってロードされるすべてのライブラリ３００ごとに１つ作成される。
バインド情報４１０には、ライブラリ３００を識別するためのライブラリ名４１１とライブラリ識別子４１２、バインド情報保存ファイル４００を作成した時点におけるライブラリ３００の最終更新日時４１３、バインド情報保存ファイル４００を作成するためにロードしたライブラリ３００のロードアドレス（先頭アドレス）４１４やそのデータ領域の先頭アドレスであるデータ領域アドレス４１５、リンケージ情報４２０、リロケーション情報４３０が含まれる。
リンケージ情報４２０には、バインド情報保存ファイル４００を作成するためにロードしバインド処理を行ったあとのライブラリ３００内のデータ領域のコピーが含まれる。
データ領域のかわりに、ライブラリ３００全体や、データ領域の一部であるグローバルオフセットテーブル３４０のみを含んでいてもよい。
リロケーション情報４３０には、リンケージ情報４２０内に含まれるバインド先のアドレスが属するライブラリ３００のライブラリ識別子４３１と、バインド先のアドレスを格納しているグローバルオフセットテーブル３４０の領域３４１に対するライブラリ３００の先頭またはデータ領域の先頭からのオフセット４３２が含まれる。
【００１５】
図６に、データ領域保存処理５００のフローチャート図を示す。
まずリンカ７００とプログラム３０１をロード（入出力装置１０３から主記憶装置１０２に読み込む）し、リンカ７００を起動する（５０１）。
次に、起動されたリンカ７００がプログラム３０１の依存共有ライブラリをすべてロードし（５０２）、プログラムと全依存共有ライブラリのリロケーションとバインド処理をプログラム実行時と同様に行う（５０３）。
次に、バインド情報保存ファイル４００を作成しオープンする（５０４）。
バインド情報保存ファイル４００は、プログラム３０１と同じディレクトリに、プログラム３０１のファイル名称の内の拡張子を除いた部分とこの拡張子とは異なる拡張子からなるファイル名称を有するファイルとして作成する。
ただし、異なるディレクトリに作成してもよく、ファイルを作成せずにプログラム３０１内にバインド情報保存ファイル４００の内容を埋め込んでもよい。
次に、バインド情報４１０を作成する。
まず、リンカ７００が作成する管理テーブル内のデータを４１１〜４１５に複写する（５０５）。
次に、データ領域全体またはその一部であるグローバルオフセットテーブル３４０を、リンケージ情報４２０に複写する（５０６）。
次に、すべてのライブラリ３００とプログラム３０１のリロケーションテーブル３３０を参照し、リロケーションテーブル３３０の各エントリのオフセット３３３に格納されているアドレスがポイントしている領域が属するライブラリ３００のリロケーション情報４３０のテーブルに、リロケーションテーブル３３０が属するライブラリ３００の識別子をライブラリ識別子４３１に、オフセット３３３をオフセット４３２にそれぞれ登録する（５０７）。
ステップ５０５〜５０７をプログラム３０１と全ライブラリ３００に対して実行したのち（５０８）、クローズして情報を保存する（５０９）。
【００１６】
次に、共有テーブル作成処理６００の実施方法を詳細に説明する。
図７に、共有設定ファイル１５０の構造例を示す。
共有設定ファイル１５０は、ライブラリ名１５１と優先度１５２が記述されたエントリの集まりである。
優先度１５２はなくてもよく、その場合はエントリの並びを優先度とする。
ライブラリ名１５１が示すライブラリ３００を共有テーブル２００に登録する。
容量などの関係から登録するライブラリ３００を限定する場合、優先度の高い順から共有テーブル２００に登録する。
優先度１５２は、リンカ７００にライブラリ３００をロードするときライブラリ名をログファイルに出力して、ログファイルからライブラリ名の出現回数をカウントし、そのカウント数を優先度とする。
ロード回数をファイルや共有ライブラリ内に出力し、ファイル内のロード回数を優先度としてもよい。
また、ロード回数のほかに、ライブラリ３００に含まれるシンボル数など別の要素を考慮してもよい。
【００１７】
図８に、共有テーブル２００の構造を示す。
共有テーブル２００内は、ライブラリ名１５１が示すライブラリ３００ごとに、シンボルテーブル２１０（各ライブラリ毎に２１０ａ、２１０ｂ・・・と表記する）とライブラリ管理テーブル２２０（各ライブラリ毎に２２０ａ、２２０ｂ・・・と表記する）を設ける。
シンボルテーブル２１０には、共有ライブラリ内のｉｍｐｏｒｔシンボルごととｅｘｐｏｒｔシンボルごとにエントリ２１１を設ける。
エントリ２１１には、シンボル名２１２のほか、関数やデータのモジュール内オフセットであるシンボル値２１３、シンボルが定義されているセクションの識別番号２１４、シンボルのバージョン番号２１５、が含まれる。
また、エントリ２１１には、テーブル２３０へのポインタ２１７が含まれる。ポインタ２１７はテーブル２１０を作成するときに設定される。
テーブル２３０は、同じシンボルの他のテーブル２３０へのポインタ２３１と、ポイント元のシンボルに関するリロケーション情報４３０を保持しているエントリ３３１内のオフセット３３３のコピーであるオフセット２３２とを含んでいる。
オフセット２３２のかわりにリロケーションテーブル３３０のエントリ３３１の識別子を含んでいてもよい。
【００１８】
また、エントリ２１１には、テーブル２４０へのポインタ２１８が含まれる。ポインタ２１８はテーブル２１０を作成するときに設定される。
シンボル名２１２が同じであれば、同じテーブル２４０をポイントする。
テーブル２４０には、テーブル２４０を一意に識別する識別子２４１と、シンボルテーブル２１０内の同じシンボル名のｅｘｐｏｒｔシンボルのエントリ２１１へのポインタ２４２、ｅｘｐｏｒｔシンボルが含まれるライブラリ３００のライブラリ管理テーブル２２０へのポインタ２４３が含まれる。
また、エントリ２１１には、同一テーブル内で検索条件の等しい次のエントリ２１１へのポインタ２１９が含まれる。
例えば、バージョン番号２１５が０のときはバージョン番号２１５を比較しなくてもいいが、０以外のときはバインド可能かどうか判断するため、ｉｍｐｏｒｔシンボルのバージョン番号２１５とｅｘｐｏｒｔシンボルのバージョン番号２１５とを比較しなければならない。
このため、バージョン番号２１５が０と０以外では、異なった検索処理を必要とする。
また、ポインタ２１７が格納されていないエントリは、リロケーションする必要がなく、検索する必要がない。
このため、図８に示すように、ポインタ２１７が０でないエントリのうち、バージョン番号が０のエントリ（シンボルａとシンボルｄ）、バージョン番号が０でないエントリ（シンボルｃとシンボルｅ）でそれぞれキューを形成することで、各キューをたどり、キューごとに同じ検索処理を実行すれば、バージョン番号が０でないか判断するオーバヘッドを削減することができる。
ライブラリ管理テーブル２２０には、次のライブラリ管理テーブル２２０のアドレス２２１、ライブラリ３００のライブラリ名２２２、シンボルテーブル２１０のアドレス２２３、ポインタ１２９のキューのアドレス２２４・２２５、が含まれる。
【００１９】
図９に、共有テーブル作成処理６００のフローチャート図を示す。
共有設定ファイル１５０を読み込み（６０１）、優先度１５２の順にライブラリ名１５１を並び替えたのち（６０２）、ライブラリ名１５１が示すライブラリ３００に対して、順番に以下のステップ６０４〜６４０の処理を行う（６０３）。
このとき、ライブラリ名１５１が示すライブラリとともに、ライブラリ名１５１が示すライブラリの依存ライブラリに対して６０４〜６４０の処理を行ってもよい。
ライブラリ名１５１のライブラリ３００をロードし、シンボルテーブル３２０を主記憶装置１０２に読み込む（６０４）。
シンボルテーブル２１０を割り当て、シンボルテーブル２１０内の各エントリ２１１の２１２〜２１５に、シンボルテーブル３２０内のデータを複写する（６０５）。
ライブラリ管理テーブル２２０を割り当て、ライブラリ管理テーブル２２０のチェインを形成し、ライブラリ名とシンボルテーブル２１０のアドレスを代入する（６０６）。
各エントリ２１１のポインタ２１７を代入し（６１０）、ポインタ２１８を代入し（６２０）、ポインタ２１９を代入し（６４０）、テーブル２３０とテーブル２４０を作成する。
【００２０】
図１０に、図９におけるポインタ２１７作成処理６１０のフローチャート図を示す。
ポインタ２１７が属するライブラリ３００のリロケーションテーブル３３０を参照し、リロケーションテーブル３３０の各エントリ３３１に対して、ステップ６１２〜６１５の処理を行う（６１１）。
テーブル２３０を新たに１つ割り当て（６１２）、オフセット３３３の値を、オフセット２３２にコピーする（６１３）。
識別子３３２が示すエントリ２１１内のポインタ２１７の値を、割り当てたテーブル２３０内のポインタ２３１にコピーし（６１４）、ポインタ２１７にテーブル２３０のアドレスを代入する（６１５）ことによって、テーブル２３０のチェインを形成する。
【００２１】
図１１に、図９におけるポインタ２１８作成処理６２０のフローチャート図を示す。
シンボルテーブル２１０のすべてのエントリ２１１に対して、ステップ６２２〜６３０の処理を行う（６２１）。
エントリ２１１（説明の都合上、元のエントリという）（例えば、２１１ａ）内のシンボル名２１２と一致するシンボル名をもつ他のエントリ２１１（例えば、２１１ｆ）が共有テーブル２００内のすべてのシンボルテーブル２１０中に存在するか調べる（６２２）。
存在すれば（６２３）、上記の他のエントリのポインタ２１８の内容を上記元のエントリのポインタ２１８に複写し（６２４）、同じテーブル２４０をポイントさせる（例えば、２１１ｆ内のポインタ２１８を、２１１ａ内のポインタ２１８にコピーし、同じテーブル２４０をポイントさせる）。
シンボル名２１２と一致するシンボル名を持つ他のエントリ２１１が存在しなければ（すなわち、ポインタが０の場合）（６２５）、テーブル２４０を割り当て（６２６）、共有テーブル２００全体で一意の識別子を与えて識別子２４１に代入する（６２７）。
エントリ２１１のシンボルがｅｘｐｏｒｔエントリ、すなわちエントリ２１１のシンボル値２１３とセクション番号２１４が共に０でなければ（６２８）、ｅｘｐｏｒｔエントリ２１１のアドレスを、同じｅｘｐｏｒｔエントリ２１１（およびそのｅｘｐｏｒｔエントリ２１１とシンボル名２１２が等しいｉｍｐｏｒｔエントリ）内のポインタ２１８が示すテーブル２４０内のポインタ２４２に格納し（６２９）、ｅｘｐｏｒｔエントリ２１１のシンボルテーブル２１０をポイントするライブラリ管理テーブル２２０のアドレスをポインタ２４３に格納する（６３０）。
【００２２】
図１２に、図９におけるポインタ２１９作成処理６４０のフローチャート図を示す。
シンボルテーブル２１０の全エントリ２１１に対して、ステップ６４２〜６４５の処理を行う（６４１）。
ポインタ２１７が０であればそのエントリをスキップする（６４２）。
バージョン番号２１５が０でなければ（６４３）、同一シンボルテーブル２１０内のポインタ２１９にバージョン番号２１５が０でないエントリ２１１のアドレスを代入し、シンボルテーブル２１０のうちポインタ２１７が０でなくバージョン番号２１５が０でないエントリのキューを構築する（６４４）。
バージョン番号２１５が０であればバージョン番号２１５が０のエントリのキューを構築する（６４５）。
【００２３】
図１３に、仮想記憶管理テーブルの構造を示す。
共有テーブル２００の領域を割り当てるとき、共有領域割当要求フラグを引数に指定して、領域を割り当てるシステムコールｍｍａｐ（ｍｍａｐは”ｍｅｍｏｒｙ  ｍａｐ”を短縮したもの）を呼び出す。
ｍｍａｐでは、共有領域割当要求フラグが引数に指定されている場合、割り当てた領域の仮想記憶管理テーブル１２０の共有フラグ１２３をＯＮにする。
共有テーブル２００を割り当てるプロセスを終了するとき、共有フラグ１２３がＯＮであれば、仮想記憶管理テーブル１２０とページテーブル１１２を複写する。
プロセスを終了するときではなく特定のシステムコールを呼び出したときに複写してもよい。
プログラム３０１をロードするとき、プログラム３０１を実行するプロセス１１１に仮想記憶管理テーブル１２０とページテーブル１１２を複写し、プロセス１１１の仮想記憶に共有テーブル２００をマッピングする。
【００２４】
次に、ランタイムリンカ処理７００の実施方法を詳細に説明する。
図１４に、ランタイムリンカ処理７００のフローチャート図を示す。
プロセス１１１の仮想記憶に共有テーブル２００をマッピングし（７０１）、リンカ７００とプログラム３０１をロードし（７０２）、プログラム３０１の依存共有ライブラリ３００をすべてロードする（７０３）。
リンケージテーブル復元処理を呼び出し（７１０）、復元できなかった場合は（７０４）、リロケーションテーブル３３０の各エントリ３３１内のオフセット３３３に先頭アドレスを加えた値をグローバルオフセットテーブル３４０の領域３４１に書き込むことによりリロケーションを行い（７０５）、バインド処理７２０を行う（７２０）。
ロードしたプログラム３０１とすべてのライブラリ３００の初期化処理を実行したのち（７０６）、プログラム３０１を実行する（７０７）。
【００２５】
図１５に、リンケージテーブル復元処理７１０のフローチャート図を示す。
バインド情報保存ファイル４００が存在しなかったり（７１１）、ロードしたライブラリ３００に対するバインド情報４１０が含まれていなかったり（７１２）、ロード時点におけるライブラリ３００の最終更新日時とバインド情報４１０内の日時４１３が一致しない場合（７１３）は、バインド情報保存ファイル４００を作成してからライブラリ３００が変更されたと判断し、復元を行わない。
復元するには、まずリンケージ情報４２０をデータ領域アドレス４１５が示す領域に複写する（７１４）。
バインド情報保存ファイル４００を作成したときと先頭アドレスが異なるライブラリＡに対しては（７１５）、ライブラリＡのリロケーション情報４３０を参照し、リロケーション情報のエントリごとに、識別子４３１が示すライブラリＢのオフセット４３２の内容にアドレス４１４を引いてライブラリＡの先頭アドレスを加え、アドレスを再配置する（７１６）。
上記ライブラリＢは、上記ライブラリＡ内の関数やデータを参照しているｉｍｐｏｒｔシンボルが属するライブラリである。アドレスが移動したライブラリＡ内の関数やデータへのポインタの内容を書き換えることで再配置します。ポインタは、ライブラリＡ内だけでなく、別のライブラリに含まれることがある。
【００２６】
図１７に、バインド処理７２０の処理のフローチャート図を示す。
まず、バインドアドレス保存テーブル１３０をプロセス１１１内に割り当てる（７２１）。
バインドアドレス保存テーブル１３０の構造を図１６に示す。
バインドアドレス保存テーブル１３０は、テーブル２４０の個数分のエントリ１３１をもつ。
エントリ１３１には、テーブル２４０をポイントするｉｍｐｏｒｔシンボルに対してバインドしたｅｘｐｏｒｔシンボルのアドレスを格納することで、同じ名称のｉｍｐｏｒｔシンボルに対する検索を１回のみにすることができる。
ここで、バインドアドレス保存テーブル１３０を割り当てずに、テーブル２４０内にエントリ１３１の内容を保存してもよい。
最後にロードしたライブラリからロードの逆順に、すべてのライブラリ内のすべてのｉｍｐｏｒｔシンボルに対してｅｘｐｏｒｔシンボルのアドレスを検索し、検索されたアドレスをグローバルオフセットテーブル３４０に格納する（７２２、７２４、７２５）。
ライブラリに対するシンボルテーブル２１０やライブラリ管理テーブル２２０が存在すれば（７２３）、共有テーブル２００を用いたバインド処理７４０を行う。
存在しない場合は、共有テーブル２００を使わないバインド処理７３０を行う。
【００２７】
図１８に、処理７３０のフローチャート図を示す。
ｉｍｐｏｒｔシンボルが属するライブラリ３００のリロケーションテーブル３３０の先頭のエントリ３３１から順にバインド処理を行う（７３１）。
識別子３３２の示すエントリ３２１をｉｍｐｏｒｔシンボルとして（７３２）、ｅｘｐｏｒｔシンボルを検索する（７５０）。
見つかったｅｘｐｏｒｔシンボルのエントリ３２１のシンボル値３２３と見つかったｅｘｐｏｒｔシンボルが属するライブラリ３００の先頭アドレスの和を、バインドアドレスとして、ｉｍｐｏｒｔシンボルが属するライブラリ３００のリロケーションテーブル３３０内のオフセット３３３が示すグローバルオフセットテーブル３４０内の領域に代入する（７３３）。
次のエントリを得て（７３４）、リロケーションテーブル３３０の最終エントリまでステップ７３２〜７３３を繰り返す（７３５）。
【００２８】
図１９に、処理７４０のフローチャート図を示す。
ｉｍｐｏｒｔシンボルが属するライブラリ３００のライブラリ管理テーブル２２０のポインタ２２４またはポインタ２２５から、キューの先頭のエントリ２１１のアドレスを得る（７４１）。
エントリ２１１のポインタ２１８の示すテーブル２４０から識別子２４１を得る。
識別子２４１の示すエントリ１３１に値が代入されていれば、他のライブラリで同じ名称のｉｍｐｏｒｔシンボルのバインド処理が既に行われているので、エントリ１３１の値をグローバルオフセットテーブル３４０内に代入する。
【００２９】
図２０に、シンボル検索処理７５０のフローチャート図を示す。
ロード順などの検索優先順位が最も高いライブラリをｅｘｐｏｒｔシンボルの検索対象３００Ｅとし、検索優先順位の順にｅｘｐｏｒｔシンボルが含まれるかどうか検索する（７５１）。
ｉｍｐｏｒｔシンボルが属するライブラリ３００Ｉと３００Ｅがともに共有テーブル２００に登録されていれば（７５２）、エントリ２１１のポインタ２１８が示すテーブル２４０のポインタ２４２が示すエントリ２１１がライブラリ３００Ｅと一致するか調べ、一致すればエントリ２１１のシンボルをｅｘｐｏｒｔシンボルとする（７５３）。
一致しない場合は次のライブラリを検索する（７５４）。
ライブラリ３００Ｉと３００Ｅの一方が登録されていない場合は、ハッシュテーブル３１０とシンボルテーブル３２０を使って、シンボル名が一致するエントリ３２１を検索する（７５５）。
エントリ３２１が見つかればそれをｅｘｐｏｒｔシンボルとし（７５６）、見つからなければ次のライブラリを検索する。
【００３０】
【発明の効果】
本発明の共有ライブラリのバインド方法によれば、シンボルテーブルを共有しているライブラリに対しては、あらかじめｉｍｐｏｒｔシンボルからｅｘｐｏｒｔシンボルへのポインタが形成されているため、名称を比較することなく、ポインタをたどるだけでｅｘｐｏｒｔシンボルのアドレスを取得することができるため、検索回数や文字列比較回数を削減することができる。
シンボルテーブルを共有していないライブラリ内の検索オーバヘッドは従来より増加することはないため、ロード頻度の高いライブラリを選んでシンボルテーブルを共有し、ロードするライブラリのうちテーブルを共有するライブラリの比率を高めるほど、検索回数を削減し、バインド処理を高速化することができる。また、あらかじめデータ領域の一部または全体を保存し、保存した時点からプログラムや依存ライブラリに変更がなければ、保存したデータ領域をそのままコピーするか、リロケーションを行うだけで済むため、シンボルを検索することなくバインド処理を完了することができる。
【図面の簡単な説明】
【図１】本発明のハードウェア構成の一例を示す図である。
【図２】本発明の全体フローチャートを示す図である。
【図３】共有ライブラリの構造を示したを示す図である。
【図４】共有ライブラリ内のテーブル構造を示す図である。
【図５】バインド情報保存ファイルの構造を示す図である。
【図６】バインド情報保存処理のフローチャートを示す図である。
【図７】共有設定ファイルの構造を示す図である。
【図８】共有テーブルの構造を示す図である。
【図９】共有テーブル作成処理のフローチャートを示す図である。
【図１０】共有テーブル内のポインタ２１７の作成処理のフローチャートを示す図である。
【図１１】共有テーブル内のポインタ２１８の作成処理のフローチャートを示す図である。
【図１２】共有テーブル内のポインタ２１９の作成処理のフローチャートを示す図である。
【図１３】仮想記憶管理テーブルの構造を示したを示す図である。
【図１４】ランタイムリンカ処理のフローチャートを示す図である。
【図１５】データ領域復元処理のフローチャートを示す図である。
【図１６】バインドアドレス保存テーブルの構造を示す図である。
【図１７】バインド処理全体のフローチャートを示す図である。
【図１８】共有テーブルを使わないケースのバインド処理のフローチャートを示す図である。
【図１９】共有テーブルを使ったケースのバインド処理のフローチャートを示す図である。
【図２０】シンボル検索処理のフローチャートを示す図である。
【符号の説明】
１００    計算機システム
１０１    中央処理装置
１０２    主記憶装置
１０３    入出力装置
１２０    仮想記憶管理テーブル
１１１    プロセス
１１２    ページテーブル
１３０    バインドアドレス保存テーブル
１５０    共有設定ファイル
２００    共有テーブル
３００    共有ライブラリ
３０１    プログラム
３２０    シンボルテーブル
３４０    グローバルオフセットテーブル
４００    バインド情報保存ファイル
５００    データ領域保存処理
６００    共有テーブル作成処理
７００    ランタイムリンカ
【図１】
2004151822.tif 000003
【図２】
2004151822.tif 000004
【図３】
2004151822.tif 000005
【図４】
2004151822.tif 000006
【図５】
2004151822.tif 000007
【図６】
2004151822.tif 000008
【図７】
2004151822.tif 000009
【図８】
2004151822.tif 000010
【図９】
2004151822.tif 000011
【図１０】
2004151822.tif 000012
【図１１】
2004151822.tif 000013
【図１２】
2004151822.tif 000014
【図１３】
2004151822.tif 000015
【図１４】
2004151822.tif 000016
【図１５】
2004151822.tif 000017
【図１６】
2004151822.tif 000018
【図１７】
2004151822.tif 000019
【図１８】
2004151822.tif 000020
【図１９】
2004151822.tif 000021
【図２０】
2004151822.tif 000022